army8735

似乎终于到了消停的日子。只买到30号的票所以请1天假，外加国庆中秋长假一共9天，够爽的了。此外hax在此篇中计划将放出史上最快的Web语法高亮引擎，给俺带来不少压力和动力啊。于是乎十一的休息就用来做jssc5 beta版的开发吧！
功能上jssc5 beta将发生以下变化：

去除鸡肋的异常处理功能。写在web上的代码基本都是本地测试运行过的，做那一点语法纠错功能没多大用，浪费功夫。这个功能还是放到以后的JAse上去吧。
重构框架。整体结构将发生一定改变，主要还是继承方面。分化更细致，有利于最终swf文件体积的减少。
增加自动格式化功能。这其实是以前同事提过的一点，在此准备加上。因web输入等原因造成录入代码缩进问题的话，就不必担心了，因为最终显示会计算缩进量（当然诸如python这样的语言就不行了）。
改善算法，优化性能。这也是最重要的！即使jssc5 alpha已经大大改善了性能，dojo的9k行代码在2秒内跑完，但理论上还有挖掘的潜力！到时候要和hax的PK一番，哈哈！

至于添加语法种类就需要广大爱好者的帮助了。我也准备陆续写关于高亮的文章，分享jssc5的核心算法和具体思路。虽然一直开源，但貌似从未有人对源代码的改善提过建议，我还是写点教程服务人民群众吧。
另外，发现alpha2里的说明alert居然显示的是beta版。上次修改改错，成超前发布了……

http://army.javaeye.com/blog/360024
起因hax对于jssc 4.2的dojo的9000行代码测试，性能差到难以想象；后来改进的innerHTML的事件侦听，结果才勉勉强强。
“今天才忙的过来测试了一下，ie、ff、chrome都试了试。
很奇怪的是，flash在这三种浏览器的运行效率居然有略微的不同，其中ff上跑完9000行代码大概是2.5秒，随机分布有时会略微低一些，比如2.4秒等；而ie和chrome都要慢一些，大概在2.7秒、2.8秒的样子。
上面只是传递到flash分析再传递回来分析结果的时间，还未加上innerHTML，假如加上，chrome就明显占了优势，大概在3.7秒左右；ff则是4.1秒左右；ie最惨，占了4.6秒。
至于js分析9000行代码能达到500ms的效率我感到很吃惊，因为之前的版本以及使用hl的结果，让我感到js的分析能力远远达不到这个要求；在flash中由于对其性能的信任，我没有用正则，直接进行的字符串遍历。有机会到要试一试正则在flash中比字符串遍历的性能到底有没有提高，提高多少。”
后续进行中，期待Dr.hax的js分析器，将会对目前js和as在分析上的局面有哪些探知和改变？

http://code.google.com/p/jssc/
众人拾柴火焰高，经过一段时间的发布和回馈，jssc4.1的版本公布出来，以供开发者们使用。这次做的比较大的革新有：css控制，自定义颜色，标记语言增强，jsp语法支持，预留接口。
1.除却高亮颜色部分外，其余已经尽可能地交由css控制。我想这也是所有人都希望看到的。
2.为了保持对word等富文本复制的功能，一定程度上牺牲了css控制高亮颜色的便捷。不过除了默认颜色外，可以使用对外提供的reset方法来重新自定义颜色。比如目前的示例就是使用：
reset({
js: {
key: “f33″
},
java: {
key: “39f”
…

源自对jssc的改进，原有的自动装载版本是先检测页面中出现的语法文件，然后零碎地一个一个去装载。
新的思路是，先制作好不同组合类型的文件，然后在检测的时候计算出是哪种组合，再整体一次性地去装载。
比如页面有a语法，就只装载a；有a、b就装载a和b的组合文件；有a、b、……g、h的就装载他们的组合。
思路是好的，因为这样减少了http请求，每一次至多只发送一次异步装载便可，然而我忽略了一个最基本的常识：有多少种组合。
用java写了个读取每种文件然后进行组合的程序，刚不久就发现了这个问题，用println语句打印，n长时间都没有结束。
试试计算一下多少种组合：c15/0 + c15/1 + c15/2 + c15/3 + … + c15/14 + c15/15，这是一个天文数字啊……