army8735

很高兴能为大家带来JAse的预览版，一款基于as+js的网页语法编辑器。在经历了jssc的静态DFA语法解析高亮的研究和JAte文本编辑器的失败之后，JAse终于能够吸取两者的经验和不足，慢慢地开发至今。开头不多说了，来看预览地址（暂且只有js解析器，其它的都是不存在的；基于Flash Player 10）。
两个都可以：http://jase.googlecode.com/svn/trunk/jase1/bin/index.html；http://army8735.org/wp-content/uploads/jase/
它的下载地址：http://code.google.com/p/jase/downloads/list
它的svn：http://jase.googlecode.com/svn/trunk/jase1/
目前只能支撑千行级代码编辑，总体性能并不是卡在解析器上，而是卡在flash本身的input上。有过经验的人可能感受颇深，何时adobe能提供高性能的textfield？
JAse基本内容分为两块：编辑器提供基础编辑功能、解析器以插件形式提供高亮功能。两者之间通过一个接口连接，也就是说所有的外部解析器必须实现IParser接口，编辑器每次的更改也都是调用接口方法。如此实现了扩展语法的功能，只要实现了接口，你可以开发任意的高亮程序。当然，我自己也写了个AbstractParser基类，可以方便地在其基础之上拓展。
编辑器的undo、redo等功能还未和解析器链接上，因此使用这些button的话可能会造成高亮错误，这并不是程序本身原因。预览版放出只是展示基本输入修改已经ok了。其它将会在后续版本中逐渐开发。
JAse的整体流程是：寻找目标textarea（如果指定id直接获取，否则以document上第一个textarea为目标）=>隐藏textarea，将自己替换掉它的位置=>加载外部解析器（如果指定syntax直接加载，否则出现界面选择）=>编辑内容=>提交内容（如果指定url则使用urlloader，否则将内容放回textarea并寻找父级form提交）。
其间动态破损、修复、显示模型经历过3次算法变更得以成型，斜线动态区分perl正则和除法的算法也经历过2次变更，让我用图来简单说下吧。

在这种情况下，每行代码首先会被解析开始状态（如注释、字符串或者普通），同时渲染标明此行是否被高亮过。这两个状态List是和每行代码一一对应的，增加随之增加，修改随之修改，删除随之删除。而区块List则完全脱离于代码行索引，自成一家。
这样做的好处是分析和显示互相分开，每次编辑器内容被修改时先有破损和修复模型来完成行状态、渲染状态和区块的操作；然后由显示模型取得可视区域再从区块List中取出索引对每块进行高亮。
但坏处也很明显，每次操作对 区块List的改动太大了，前面增加一个字符，会导致所有后面的索引进行修改（自增1），因此很快就被废除，有了第2种想法。

废除区块索引。每次编辑器内容修改，都去计算行状态并且设置涉及行的渲染状态为否以便重新渲染。这个算法对分析阶段来说有了极大的便利，但是在显示阶段却叫苦不迭——在渲染每一行代码的时候，都要根据行状态重新对此行代码进行一遍DFA解析，而这个工作在前面的分析阶段已经做过了（大部分）。同样的功能需要两份代码显得冗余，要合并到一起的话又会变得难以维护，而且多分析一次也显得没有必要。
在经历了一段时间的纠结后，最终还是变更到现在这个样子。

区块List成为二维的，亦和每行对应。然后List中的List保存索引。不过和第1种方式略有不同，之前保存的是绝对索引（字符串的下标），而这里保存的是相对索引（相对于行代码第一个字符而言）。这样每次渲染的时候，只要知道行代码的第一个字符索引，然后遍历这行对应的区块List，相加得出绝对索引即可完成显示。而且每次修改后，后面行的相对索引都无需变更，综合了以上两种方法的优点。
至于斜线的动态区分，最终情况和这类似。静态DFA解析的情况下很容易确定一个斜线的含义究竟是除法还是正则——因为源代码扫猫是从头至尾的。动态情况下因为不确定性，不可能每次修改都从头遍历代码，代价太大了，最好能够从当前行或者前面几行判断出。最初我采用向前回溯的方式，这显得很愚蠢，而且前面行还可能存在单行注释、多行注释等情况干扰（词法分析无需考虑，因为注释空白一开始就被剔除了），基本上行不通。
后来我为每行增加一个布尔值来标明行起始状态如果出现斜线的话它的含义是什么，每次内容修改也会根据解析情况重置它，就和重置行状态和是否被渲染一样。
另外曾经让我非常头疼的一个地方是事件侦听部分。我希望的是每次编辑器内容修改时，所触发的侦听在修改后立刻执行，而as中所有的事件侦听都是在之前执行。这导致使用解析器进行分析显示的时候，实际上代码还根本未发生改变，显然这是个悖论。唯一的做法就是将侦听中模拟事件率先执行，然后通过preventDefault()来取消默认事件发生。这里有个问题，那就是像删除这样的事件（无论del还是backspace或者选区替换）是无法被取消的。所幸的是最终这些难题被一一解决——包括TAB键不能使用，感兴趣的可以查看编辑器源文件来了解是怎么做到的。只关心外部解析器的话不用考虑。
试用过程中有任何问题、反馈或者建议请不吝提出。在beta版完成之后，也会出系列文章来详细介绍JAse的所有技术，就像jssc一样。

JAse开源项目缓慢进展中，许多地方和许多算法不断地颠覆、重写，这也是预料当中的。目前来说总体架构是不会变的了：以一个swf文件为基础提供文本框和一些菜单栏的基本功能；语法分析插件以不同语法分发为各自的swf文件，用到的时候才去读取。
当然，所有的语法文件都是面向接口编程的（实现IParser接口即可，这个理念继承自jssc5），这也使得按需加载成为可能。废话不说，来看几张预览图。
开始的选择画面：

第一个被我“强奸”的是js（最熟么），其它的会陆续添上。我默认放了一段Mootools的代码：

拉一拉滚动条，性能还不错，就是有不少bug还没修正：

至于语法编辑器用到的破损、修复、高亮模型，我非常感谢http://www.cppblog.com/megax/archive/2008/07/09/55753.html这篇文章给予的提示，同时也感谢其作者和我互通邮件的帮助。不过Megax所采用的依然是分区正则法，并非DFA状态图分析。而C++的性能远非as3所能匹敌，所以JAse目前仅能做到千行级代码，上万行后就会感觉到卡。
as3的性能瓶颈其实并不是主因，主因是textfield的性能太弱。实际测试中只是在第一次装载大量文本（万行）会卡，在拖动分析的过程中却非常流畅。今天我装了CS4（以前一直用CS3），启用了GPU硬件加速来提高渲染textformat的速度，所以如果不计textfield的拖后腿的话，预计是能达到十万行的量的。如果分析状态的数据结构由数组换成Vector（类似Java的泛型ArrayList，基于性能考虑我决定JAse将基于Flash Player 10），那么百万行级也不是不可能。
所以在JAse基本完成后，如果自定义优化textfield的性能，则是重点。目前思路有点苗头，是否能实现就难说了。另外Text Layout Framework中并未包含什么高效的input组件，本来还想瞅瞅，结果失望而归。

第三代（个）预研项目JAse，近日终于被通过了！仔细看一下邮件日期，是4月10号。
在2007年初的jssc刚开始开发时，我就想过这只是静态的语法高亮，假如是累死ide那样的拥有动态、输入、提示、纠错的该怎么办。时隔两年，当jssc取得不错的成绩时，JAte应运而生，带我走进文本编辑器的领域。
然而既是如此，类似ide的念头还在，但却无从下手。所以我努力地去啃编译原理，夜以继日地思索解决方法、算法，甚至希望在梦中能够如发现DNA双螺旋结构一般灵感突现。遗憾的是，至今没有什么实质性的进展。同时可喜的是，我终于在网络上找到一个有点类似的项目——MegaxEdtor，并且也和作者取得联系，期待他精彩的博客解说~
地址：http://www.cppblog.com/megax/archive/2009/04/10/75830.html
接下来才是正题，我的JAse被通过了！
要在code.google.com申请新的开源项目JAse（参见JAte名字来历），结果和sourceforge有冲突，没办法只好和冲突作者取得联系，以求得他的同意。这要多亏了地道的帮助，和对方答复了几封邮件，最终取得成功。
几封邮件纪念如下：
—
Donnerbauer 发送至 我
Hi out there,
could you please tell me, what kind of project your “jase” is (compared to mine)?
Regards
Ruediger
—
army8735  发送至  Donnerbauer
Thanks…