posts - 76,&
comments - 621,&
trackbacks - 0
阅读排行榜
评论排行榜
很多人可能没有听过tab trigger这个功能，那么诸位可以google一把即可知道其为何物。本来我是打算把这样的功能放到插件里面做的，可是一想到最后能为我的编辑器开发插件的，在初期估计也没啥人，于是乎还是在内核上给予支持吧。本篇文章即是分析如何去实现该功能的，事实上，我已经在MegaxEdit基本上实现了。不过相较于TextMate功能有所缩水。缩水的原因主要是因为我采用了正则表达式去实现的，而绝大多数正则表达式库是不支持嵌套的(本人使用了日本的鬼车正则库)，所以在我的编辑器里变量里面不可以再定义变量。在我的编辑器里面，这个东西不叫TextMate上的Bundle，我给起了个名字叫HotText, hoho~~~首先我们看一下下面的语句：for (${1:unsigned int} ${2:i} = ${3:0};&${4:& ${5:count}}; ${6:++}) {&&& $0\}基于上面的形式我们作出如下定义：变量：&&& 变量以${数字:内容}的形式开头, 内容可以为空, 比如${1:name}, ${2:test}, ${3:}引用：&&& 这里面的引用是指对变量的引用, 比如 $数字, $1, $2, $3之类的常量：&&& 编辑器提供的常量，比如${FILE_NAME}, ${TIME}规则：&&& 变量不可嵌套变量, 变量必须顺序定义，顺序引用经过上面的规则，这个for语句就变成了下面这样：for (${1:unsigned int} ${2:i} = ${3:0}; ${4:} & ${5:count}}; ${6:++}) {&&& $0\}Ok, 我们看一下典型的效果，当用户输入for语句的时候，编辑器应该显示出：for (&unsigned int& i = 0; i & i++) {&&& &&& }&&部分为光标选择区域。聪明的读者头脑里面应该马上知道如何构造了，其实也就是几步正则替换，因为文本非常小，所以效率是非常高效的。伪代码如下:
const&int&MAX_HT_CNT&=&16;for(&int&i=1;&i&=MAX_HT_CNT;&i++&){&&&&&&&//首先替换变量&&&&string&strF&&&&strFind.Format(&"\$\{%d:(.*?)\}",&i&);&&&&string&strR&&&&strReplace.Format(&"$1"&);&&&&//在进行替换的时候我们同时要保存该变量Pos和长度信息&&&&//正因为如此,我们在定义了上面的规则，变量要顺序定义，否则就乱序了。&&&&GetSearchPos&Length();&&&&RegexReplace();&&&&GetBackRef();//在这儿获取一下上面的()中内引用内容,在进行一次替换&&&&//替换对变量的引用&&&&string&strR&&&&strRef.Format(&"\$%d",&i&);&&&&RegexReplace();&&&&//到这儿对变量1替换完毕}
上面是非常简单的逻辑。因为这东西要和编辑器结合，所以有一些数据结构是必要的。最重要的要属上面循环中变量的位置和长度信息了。有了它我们才能够实现HotSpot(热点即变量)的跳转。在这里，我简单描述一下我的编辑器的数据结构:
//&这个存储了每一个变量的信息struct&CTextSpot{&&&&CText&pCT&&&&int&nP&&&&CTextSpot(){&&&&&&&&pCText&=&0;&&&&&&&&nPos&=&-1;&&&&}};//&保存了HotText的基本信息class&HotText{public:&&&&int&m_nDocO//HotText应该从Doc中哪个偏移开始插入&&&&CText&m_T//原始文字&&&&CText&m_RetT//替换后的文字&&&&CTextSpot&m_List[&MAX_HT&];//最多可以有几个变量&&&&int&m_nSpotP//指向当前Spot,这样在Tab跳转的时候我们就知道该跳到那个Spot上了}
这些HotText均保存于Map之中，根据当前的输入进行查询，思路还是很简单的。和编辑器的结合，基本上就是一个Replace命令，用本次输入产生的HotText替换掉上次的HotText.因为大部分的HotText都很短，所以几乎不会浪费内存。EmEditor则是只对用户最后的输入产生Insert命令，虽然节省了一点内存但却失去了UndoRedo的能力，到底哪个好，也不好说。MegaxEdit是采用的前者。关于HotText的取消:用户在输入的时候不能总处于HotText状态中吧，比如用户按下了方向键或者其他快捷键，这个时候我们要取消HotText的功能，恢复Tab键本来的作用。那么如何取消呢？其实这东西和编辑器结合过于紧密，在MegaxEdit中是这样来实现的：1. 取得当前光标的偏移量 offsetA2. 取得当前HotSpot的尾部偏移量 offsetB = m_nDocOffset + HotSpot.nPos + HotSpot.pCText.GetLength();3. offsetA != offsetB, 即取消当前HotT到此，逻辑即全部结束。虽然我们实现了一个缩水版的tab trigger，不过根据我的研究，这几乎可以满足绝绝绝绝绝绝大多数的应用，至少比Notepad++上的QuickText要强多了。不占用 CPU，不占用内存，完美UndoRedo， 够用了。欢迎讨论。
阅读(2543)
&re: 编辑器制作之tab trigger
很好 期待中&&&&
&re: 编辑器制作之tab trigger
哇噻，时隔近一年后的一篇&&&&
&re: 编辑器制作之tab trigger
我没用过TextMate，所以也不知道Bundle的表现。但是我比较疑惑的是这个特性在实现上的主要难点在哪里？&&&&
&re: 编辑器制作之tab trigger
@missdeer坦白的说做成完全TextMate那样的话，还是有一定的难度的，首先你得自己写个解析器，去解释用户定义的自动完成脚本。我为了省事，去掉嵌套变量，单纯用正则来做了，效果还不错。最大的技巧是光标的跳转。不过它和编辑器结合太过紧密，所以我没有写出来。如果你没有试过bundle，你可以下个最新的EmEditor，它也实现了，而且不错，原理跟我说的差不多，从它的bundle文件可以看出来。&&&&
&re: 编辑器制作之tab trigger
@megax
编辑器杂谈之二 Snippet
很高兴没看到MegaxEdit没自行实现正则库，前段时间在MissDeer的博客中随手写的一篇“编辑器杂谈”中还提到了这个，开发应有所为有所不为，什么都自行实现且不论是否可以写得更好，也实在没有必要，当然例如Emacs的Richard Stallman样样精通的超级大牛除外。“编辑器杂谈”主要是针对Scintilla系编辑器写的，也评论了点现有知名编辑器，随附在后，希望一点心得有点小用。
不过文中有几处小错还是需要指出，估计Megax是不是没有苹果机器实际试用和深入研究过Textmate，所以不太清楚？
其一，Textmate的这个功能不是Bundle，而是Snippet，Bundle功能比这个要重要和强劲的多，Bundle构建了脚本与编辑器以及系统的关联，类似于脚本宏，MacOs上脚本体系比Windows要好很多，自带的脚本也远比Windows的JavaScript、VbScript要丰富，当然Windows的Com也异常强大，不过苹果在脚本体系的人机交互上远比Windows要好上很多。而Snippet则基本上就是文本段落辅助完成，其实Visual Studio里面就有Snippet功能，不过估计使用和研究的人更少，毕竟不是很明显的功能。Vim和Emacs也早有插件，或多或少也实现了较完整的Snippet。
其二，Oniguruma正则库，也就是鬼车是支持循环嵌套的，其自带的帮助中写得很清楚，而且还举了实例，Megax在东京呆了这么多年，即便英文的帮助没注意，日文的帮助也应该至少读一遍的。应该说，最近流行的正则库大多数都已经实现了嵌套匹配，如脚本语言Perl、PHP、开发平台.Net、Java的正则库，以及正则库Greta等都是支持嵌套的，这个在O'Reilly《精通正则表达式》一书中有详细的描述。当然1.9.0版本之后采用Oniguruma的Ruby自然也支持嵌套正则。不过也正由于Oniguruma合入了Ruby，因此现在Oniguruma的最新代码已基本合并入Ruby开发，可惜的是，Ruby加了很多专有的定义进去，使得剥离一个最新的Oniguruma已经很难了。最容易为第三方集成使用的Oniguruma也许永远都定格在5.9.1了吧。
其三，正因为Oniguruma支持嵌套正则，所以TextMate支持Snippet嵌套变量也就不足为奇了，因为TextMate的正则库正是Oniguruma的Cocoa移植版本，也许是OgreKit。当然由于Textmate商业软件的源码不可见，也不排除TextMate直接使用字符串函数进行解析，因为Snippet本身并不复杂，纯字符串解析也很容易。目前Snippet做的比较完善的除了TextMate，还有Intype一样的支持嵌套变量，但是e TextEditor就只能支持简单的文本了。
其四，写伪码时最好也要注意语法，strFind.Format( &\$\{%d:(.*?)\}&, i ); 肯定编不出正则的，Escape转义字符应该写\\，而不是\，要不然引号就先使用\转义了，再往下就自然出错。这不是TCL，TCL可以使用{}来规避，而C则不行。
不过总得来说，基本上Snippet的实现就是这样了，不过依然有两点需要改进，一是变量的顺序，其实没有必要规定顺序。当然，如果按一次处理一个序号自然会引入顺序问题，但是如果一遍先将所有编号区域全部找出存储，并记录位置信息，再行一次性替换，就可以解决顺序问题了。其二，Tab键并不是一个完美的键，无论是TextMate，还是Intype等，都只可以用Tab前进，而无法后退，这是因为Tab本是就是缩进键，此处挪作Snippet用，从而导致一个键二次定义，从用户角度上而言是不可取的，使得用户在Snippet过程中无法缩进，例如复杂点的段落，自动缩进不完美的情景下，用户就只能退出Snippet再行修改了。因此目前TextMate等多半是在编写Snippet时就预设好缩进，在Snippet时仅仅依据上一行进行整体缩进，从而一定程度上避免了这个问题。但是也因为很难做完善，所以Shift-Tab并没有用来实现Snippet的回跳，依然还是定义为减少缩进。这个问题在 Mitchell Foral 的Scite-Tools中有提及，因此Scite-Tools在Scite的基础上使用Ruby实现了Snippet时，并没有使用Tab键，而是Ctrl的组合键，这样就轻松的完成了前进和后退，如果TextMate等跳出Tab的圈子，自然一样可以轻松后退，不过如果决定权交到用户手中也许会更好。Mitchell Foral 基于Scite的后来的最新Mod作品，如TextAdept等，Snippet又用lua重新编写了。由于Snippet自身就是Ruby或Lua脚本的便利性，Mitchell的Snippet从某种意义而言应该是比TextMate更为强大，因为此时Snippet已经是具有完备功能的脚本段，有点类似于Bundle，而不再仅仅是一段字符串了。
Snippet作为一个非常便捷的编码辅助功能，也依然在不断发展，自解释应是目前的最新阶段，其代表就是Zen Coding，作为快速开发的典范，类CSS的语法，使得编写Html等网页语言非常迅捷，可惜，其作用域由于语法特殊性，估计也很难走出Html的编程范围了。&&&&
&re: 编辑器制作之tab trigger
@megax
编辑器杂谈之一 Scintilla（上）
HuaHope
Scintilla的相关项目很多，官方网站的related中就列举了相当多的。只是恰如有次见到一个评论中说的，自从有了Scintilla，几乎大多数的编辑器都很少自己编写“编辑器”了，完全是加个外壳，当然编辑器控件SynEdit(delphi)、CodeMax等也功不可没。
就Scite_ru、Scite Latex IDE而言，其实并不算是出众的Scintilla相关项目，而ScintillaLua虽然是这里看到了才知道新有了这个项目，也刚去下载了（可惜zip的解压失败，就下载的tgz的），但只是看看配置文件就知道了，其也只不过是Mitchell Foral的一个副产品，之前Mitchell Foral就有Scite Tools和Scite St，再加上后来的Textadept，这几个都是差不多的实现，除了补足SciTE的动态着色之外，还有一个snippet功能，不过也许ScintillaLua可能独立后实现的比以前更完善吧，没有看代码，但是lexer配置倒是丰富了很多，终于几乎实现了Scintilla的所有支持语言，另外一个最大的改进就是许可证终于换成了BSD，比Scite Tools的LGPL要更开放些，以至于SciTE_ru最新的版本就以及迫不及待地整合了ScintillaLua，实现了外部lexer的支持。不过从设计角度而言，Lexer采用外挂的lua脚本，处理能力毕竟有限，虽然使用llpeg灵活性增强了，但是效能无疑更低了，即便是luajit，估计也无法对付稍大一点的文件。Scintilla比较好的项目，Filerx算是不错，可惜很久就不更新了。其余的，就编辑器而言，都没能走出Scintilla的限制，也自然更难超越Scintilla自身的光环。
其实国内基于Scintilla的项目也很多的，但真正自己写编辑器的也有，比如已经商业化的Aptedit，还有MegaxEdit等，MegaxEdit的博客中讲了一些编辑器实现技术，比如折叠等，和Scintilla实现是类似的，只是很可惜，由于没有实物，所以无法评测其功能和性能，不过虽然上面说大多数编辑器完全拿来义不好，但是MegaxEdit完全自己写，甚至字符串查找KMP算法也自己实现，实在也太过于自力更生，看日志好像还自己实现了可配置的状态机，距离正则库也差不远了，只不知道正则库是否也自己写完了：）Megax还曾经到FlexEdit网站评论过，虽然指出没有突出优势的缺点也不算错，但从其日志上描述的技术思想中感觉块着色算法虽然比Scintilla的要好，但是还是不够完善的，比如不允许循环嵌套语言，其实这个限制并不应存在，除非刻意的构造，否则几乎所有的文件中语言再怎么嵌套都是有限的，也是可以分析着色的。另至于嵌套只允许4个子语言，对于html而言就未必够用，而且如果不独立线程，即便是块着色速度对于10万行以上的大文件也依然很慢，不过Megax从09年2月就消失了，一直到这个月才又冒出来更新日志，感觉依然对lex很纠结，估计还有一段路要走。当然还有MadEdit，也是很不错的，16进制和内码做得很好，只是大文件处理能力有限，界面也不够美观。至于国人的flexedit、notepad++等，也多半只是加个壳而已。没有太多需要说的，Notepad++的插件系统倒是不错，现在的插件也非常的多，只是其中很多没有实现界面的插件并没有太多的必要，如果Notepad++实现ScitTE中的lua脚本扩展，编写脚本即可扩展类似的功能，实在没有必要做成dll，从一种扩展走向另一种封闭，只是没有深入研究过其插件系统，感觉整体设计还是不错的，不过距离几乎完全插件化的Eclipse估计还是有所差距。
而国外的自己写编辑器模块的就要多一些，比如e texteditor，intype（早期是自己修改的Scintilla，后来好像是觉得Scintilla不够好，重新实现了自己的）,sublime text editor等等，其实编辑器技术最难，也是最核心的就只是如何对内存进行Gap操作，如果完成了这个，效率足够，其余的真的很容易，Codeproject上有一些相关的教程，但估计看完的并不多。至于Komodo、XmlSpy、LuaEdit、Autoit的编辑器、Adobe的Creative Suite套件中的ExtendScript Toolkit等，由于产品定位不同，直接使用Scintilla的编辑器也无可厚非。何况Komodo、Adobe都曾对Scintilla社区有贡献过代码，比如Scintilla中的Mac代码很多都是Adobe贡献的。
至于MacOs下的Textmate也是自行实现的编辑器模块，不过没有测试过大文件性能，MacOs下的开发有个很好的优点，很多都是苹果内置实现了，而且MacOs本身就与脚本相当紧密，甚至自带了tcl、perl等，shell也很好用，所以MacOs下的编辑器都实现的比较好，比如BBEditor等，xcode使用起来也非常方便，不过很奇怪的是，xcode的snippet、自动补全等在输入代码后会用灰色字体将后续的补全，但是如果用户不想要这个，又会自动清除，重新补全，但实际使用中感觉文本晃动的不太舒服，尤其是多行补全时，也许有人喜欢这样的风格吧，不过也可能有设置可以关掉吧。
当然提到编辑器，不能不提的是Unix下的Vim和Emacs，两者各有千秋，不过也有各自的缺点，要不如果过于完美，凭近乎传奇的悠久历史，早就一统江湖了，呵呵。目前两者在windows平台都还算小众，另外，两者设计也不是绝对完美的，比如vim的键盘映射，命令的内部代码全部是硬编码，如dd删除行，以及yy等就是判断是否d或y重复而实现的，虽然新命令可以做map，也依然可完全定制键盘序列，但是如果代码实现能够将键盘序列与对应功能任意由用户绑定，或者内部使用表来绑定键盘序列和其默认功能，即更灵活些就更好了，这样修改起来也很容易就可以改进键盘绑定，而不是现在功能处理分散在代码的各个地方。UltraEdit没什么太多要说的，虽然不及Vim和Emacs悠久历史，但也再过几年就开发了二十年了，足够长的时间，也足够做很多改进了，事实也是如此，现在的实在是太庞大了，一个编辑器要几十兆，不过就功能而言，除了大和全之外，16进制还可以，列模式虽然也不错，但对于东亚等复杂文字处理还是不够完善，至于作为重要特性的大文件处理性能其实也不好，用临时文件时先要复制一个副本导致速度很慢，而且占用大量硬盘，不用，就无法撤销编辑，实在是两难。何况现代编辑器的许多理念，如自定义着色Lexer、snippet等，也是很难见到。扩展性也不够好。而就体积而言，同样庞大的Emacs就远比UltraEdit要强上非常多，可见UltraEdit之臃肿，至于提到的大文件和扩展性，EmEditor就很不错，EmEditor通过基于内存映射的框架实现了一个很好的大文件编辑功能，不过EmEditor很多都依赖于插件，未必是很好的设计。如果不像Eclipse那样，有众多的拥蹙开发插件的话，而只靠开发者本身开发的话，插件系统用处并不大。更何况虽然EmEditor的脚本扩展做得不错，好像也实现了com，但是多数插件仿佛并不是脚本实现的，这和样就无形增加了第三方开发难处。开发Visual Assist可以make money，给EmEditor开发插件，估计很少有用户这么做吧，幸好EmEditor还是卖出了不少钱的，开发者一直相当积极的升级，一次版本都能发几十个beta版，现在已经是版本9了吧，相对而言，EmEditor升级对于现代编辑器功能的关注还是不错的，9中就已经实现了snippet，比起UltraEdit经过15个版本还停留在Templates模板功能上，每次的升级只是围绕着彩色的tab页，界面配置的角色化，查找窗口中的单行编辑框变成多行编辑框，应该算是比较上进的了，不是说UltraEdit做的改进不重要，只要是用户使用到的，都是最重要的功能点，但是核心功能的改进更不可或缺，否则界面做得再好，编辑效率提不高，有什么用呢。说了这么多编辑器，也提一下Editplus，虽然功能不算突出，但设计的很简洁，很中庸型的编辑器。至于pspad，开发了很多的功能，甚至包括计算器，颜色拾取器等，确实很辛苦，但是依然不够稳定，而且比起同样是delphi编写的RJ TextEd来说，功能也并不算丰富，界面也逊色些，其实delphi的界面库很好用，换肤功能也很强，虽然也许换肤对于编辑器而言过于花哨，但是只要是会接触和使用到编辑器，而不是只知道记事本和word的，编辑器多半是最最常用的工作或学习的不可或缺的工具。因此如果拥有一套美观的默认外观对于用户使用也是很有用的，毕竟爱美之心人皆有之。
&&&&
&re: 编辑器制作之tab trigger
@megax
编辑器杂谈之一 Scintilla（中）
HuaHope
撇开其他非Scintilla的编辑器不谈，就Scintilla编辑器而言，最大的缺点，也是很奇怪的，就是几乎每个项目都很少会修改Scintilla内部，Mitchell Foral的Scite Tools和Scite St、Textadept、Scintillalua算是少有的另类，其余的真的很难看到做较大功能改进的，也许为了升级更新编辑器模块方便，甚至静态编译的都很少，一律的动态链接，几乎都是完全的拿来主义。说实话，如果编辑功能只是工程的一部分，那也符合重用的开发理念，但很多工程本身就是开发编辑器，也一味的用而不改进核心功能，不仅使自身无法提高层次，不利于Scintilla发展，更使得现在大多数Scintilla同质化非常严重，譬如，Scintilla的列模式几乎每个项目都在期待，但是由于Neil一直很难决定如何很好的实现virtual space，所以所有的相关项目的列模式为人诟病已经很多年，直到2.0中实现了多选区编辑和virtual space功能才算是了却了几年来的心愿，而且就目前而言，列模式还实现得并不完善，比如列模式下的粘贴文本就无法像UltraEdit一样粘贴到每一行。不过1.76之后的代码就很少跟踪了，也没有去看这个新功能代码如何实现的，其实virtual space和列模式功能要实现很简单，只要在原先选区的Anchor和current基础上增加virtual Anchor和virtual current即可。另外每个项目都知道Scintilla内存消耗是文本自身的两倍，仅仅是为了实现style，Neil在实验项目中SinkWorld虽然对此作出了改进，但是SinkWorld进展实在非常缓慢，类似于Scintilla与SciTE，展示SinkWorld的Tentacle 也很久没有更新了。而且SinkWorld中的改进是针对于Scintilla中style的8个bit位128种style无法充分支持html这种可嵌入子语言类型很多的扩展型语言的，要实现的是动态长度的Style，这样必然会带来更严重的内存问题，其实就内存而言，打开相同的文件，Vim消耗的内存是相对而言比较少的，基本上比实际文本多一些，而其他的编辑器大多也是内存消耗很多，甚至有三倍于文本自身的，但其实内存问题并不必要用现在的style实现方式的，动态数组是一个更好的方式，不仅可以做到内存占用几乎与文本自身大小接近，而且对于识别同一style的起始结束和结束都是很有益处的，复杂度甚至可以做到常量，而不是现在的线性，需要逐个byte的去比对搜索，这点对于基于代码做分析，比如识别注释、字符串等块状文本有很重要的意义。当然，Scintilla目前最大的弱势还是在于正则库，Regex实在是一个过于简单的正则引擎，虽然Scintilla在1.77版本中就实现了正则引擎的外接口，相关项目，如Programmer's Notepad也已经实现了使用Pcre和Xpressive分别用于Scintilla内部和配置的正则匹配，但是多半还是需要针对各个引擎库写迭代器的，这样就不免又造成了一定的门槛，使得现在大多数项目依然使用内置的功能很弱的正则库。而没有一个优秀的正则库作为支撑，就很难实现自由度很高的自动缩进、函数识别等，更重要的，Lexer就无法做成可配置。用户自由的实现如vim、emacs、textmate那样编写lexer扩展就无法成为可能。而缺少这些，对于现代的编辑器功能而言，不免是一个很大的遗憾和功能劣势。除此以外，对于大文件的支持也是Scintilla的弱势，由于内部的设计导致的双倍内存问题，使得大文件支持更为捉衿见肘，相关的一些功能，比如括号对匹配高亮，以目前的SciTE内部实现是搜索全部文本，这显然在大文件时会导致界面假死，而Notepad++则弥补了这个缺陷，将搜索限定在上下搜索2000行而已，但这对于大文件又显然是不够的。诸如此类的功能，对于大文件而言便不免会有所缺失，不过Neil很早就宣称，Scintilla并不是为大文件设计的，所以也无可厚非。何况大文件的需求比较特殊，并不能完全做到统一，也许Neil除了认为难以实现之外，还考虑到了大文件操作与系统是紧密相连的，比如windows的内存映射，其他平台的实现就不尽相同，因此严格意义上，就Scintilla不与具体系统捆绑的设计目标来说，这并不是Scintilla遗漏的功能，实际上，从某种意义而言，Scintilla已经提供了很好的框架，足以支撑外部项目使用系统函数和算法更好的处理大文件，不过所有的项目鲜有见到实现了大文件操作的，包括最流行的项目Notepad++。当然大文件本身就是很难做处理的，即便是宣称大文件处理比较好的EmEditor，打开普通的非着色文件还好，但一旦遇到着色的如cpp文件，也一样会很痛苦，因为着色是需要遍历每一个字符并采集属性的，因无法见到EmEditor的Lexer代码，不知道如何实现的。但是要解决着色问题，前提必然是Lexer线程独立，而非Scintilla现在的单线程，虽然Scintilla内部设计了一些位置信息，可以接续着色等，但对于大文档，依然会有明显的延迟。Vim要好些，可惜也没有去研究过其Lexer代码。上文提到的Megax的分块着色是一个好的解决方案，但是多线程依然是最终解决的不可或缺的，其实Scintilla Maillist中很早就几次提过多线程着色，但是Neil认为难度很大，也没有人提出可行的方案，也就不了了之了。与大文件类似的，缺失的还有全面支持UTF8，和16进制，vim和Emacs等早已经实现了内部完整支持Unicode，当然实际内码是UTF8，因为对于许多字符集而言，Utf8比Utf16等编码方式要节省内存，而Scintilla则由于扩展性，采取设置内码方式，虽然也可以支持UTF8，但是兼容多内码的设计带来了很多的效率问题，比如查找时，对于MBCS，就需要判断当前字符是否是leading字符，这样很显然会非常慢，这从SciTE设置内码为CP936等代码页后的搜索就可以很明显的看出与其他编辑器的速度差距，而且支持单一的UTF8可以更好的识别文本，比如中文的书名号配对《》，这是多内码设计所无法实现的，因为项目无法对每一种代码页都做分析，做出特定的表来识别，不过这个错不完全在Scintilla，外部项目本身可以弥补这些缺陷，可惜从开源的一些编辑器实现上看，并没有编辑器如此做。至于16进制，UltraEdit实现的比较好，虽然一些编辑器项目也实现了16进制，比如FlexEdit、Notepad++、Scite_RU等，但是FlexEdit是另外写的16进制编辑模块，不是用的Scintilla，Notepad++也是一样，HexEditor插件也是另外实现的基于树形列表Treelist的16进制编辑控件，而SciTE_Ru虽然是通过lua脚本实现了原生的Scintilla十六进制编辑，但是类似于Dos时的小窗口编辑实现的并不算好。很奇怪的是，1.78版本中实现的两个主要新特性之一的文本边栏Text margin就完全可以很好的实现16进制编辑时的偏移量显示，但是依然还是见不到有项目基于此自行实现的16进制编辑功能，也许一样要等到Scintilla完全实现内置16进制编辑才会普及吧。至于1.78中添加的另一个新特性注释行Annotation lines，很类似于xcode中设计的出错显示，不过也许visual studio等windows开发环境习惯于将错误输出到Output窗口，而只有要显示汇编时才混合代码和汇编一起显示，所以Annotation lines也是应用寥寥，平心而论，Scintilla就编辑功能的覆盖广度已经做得比较完备了，许多功能并不弱于vim、Emacs等超级编辑器，但是问题在于各项目组合基础功能之后的深度还不够，以至同质化严重的同时，各项目也功能平平，比如自动缩进，vim实现了四种缩进，auto、smart、c、以及indentexpr，而emacs则实现了gnu、java、linux、python、user等多种成熟的缩进风格，提过组合，在vim和emacs中几乎常见的缩进风格都很容易实现。而SciTE实现了简单的自动缩进后，大多数基本沿用，因此缩进都不够智能，而Notepad++的插件NppAutoIndent则从一定程度上改进了Notepad++的自动缩进，可见自动缩进并非是Scintilla不能支持，而是大多数项目设计使用不当。当然SciTE还展示了lua脚本扩展，以及提过windows的消息扩展等，如Filerx就是使用外部SendMessage来操作SciTE，效果很好，可以录制和重放操作，对于文本编辑器而言，lua脚本使用SciTe的库函数接口已经足够实现绝大多数文本功能扩展。但可惜的是，大多数项目没能很好的继承SciTE这种良好的扩展性，大多数项目没有实现类似的lua系统，就是有扩展性也是另起炉灶，如Notepad++自行实现了插件系统，固然设计的还不错，但却失去了脚本的灵活，而programmer's notepad等虽也自行实现了采用python等其他脚本语言的脚本扩展，可惜自由度却还是不如SciTE。当然同样可惜的是，依然有些扩展是需要有界面的，尤其是运行时需要引入参数的，而单纯的lua无法扩展界面，lua的几个界面库如iup，tckUI等也不能很好的担当大任，使得单纯的SciTE中的lua扩展使用并不是特别方便，再加上SciTE本身非界面化的配置不够友好，导致其用户并不是很多。至于lua和wxWidgets或者Qt虽然可以较好的互动，但是前提是SciTE不是采用这些库开发的，而即便有项目以这些界面库开发，使用lua来控制，估计需要做的事情依然很多，不够轻量化，也不符合现在网络化的发展趋势。&&&&
&re: 编辑器制作之tab trigger
@megax
编辑器杂谈之一 Scintilla（下）
至于比编辑器更复杂的IDE，情况也差不多，大多数IDE现在都是Eclipse化了，另外由于Borland的黯然离开，除了微软自家的Visual Studio，考虑到跨平台，IDE多半用的不是java就是wxWidgets，如另一个与Eclipse齐名的NetBean也是java实现的。而一些小型的IDE，如Code::Blocks、Komodo等，出于开发方便，最主要的核心组件之一也很少自行开发，直接使用了Scintilla，其实，无论是从开发角度还是使用角度而言，编辑器不仅仅是IDE的基础，也同时已经具备了IDE的初步雏形，尤其是除了少数几个巨型IDE如微软的Visual Studio，Sun Java Studio，IBM Rational（基于Eclipse），以及一些CPU厂商，如Intel、Motorola的IDE等，可以有足够的实力考虑和实现包括编译器、调试器、编辑器、版本控制器等各个组件的设计开发衔接以更好的整合之外，大多数的IDE基本都是外挂式的，比如挂上GCC，SVN等等，而这些，很多编辑器其实也都可以做到，甚至包括外挂调试器，只是相对而言，由于设计目标和定位不同，IDE实现和整合的功能更多，IDE的插件系统一般也更复杂也更完善，扩展功能更容易，而这对于大多数单兵作战开发的编辑器就很少会充分的考虑到。当然类似的还有SlickEdit、UltraEdit Studio，以及以代码分析著称的Source Insight等第三方IDE，至于Emacs也可以算是IDE吧，对于此类IDE，优秀的编辑器都一样是其基础，不过就以Source Insight而言，其定位就是编辑代码文件，因此大文件操作就很少考虑，否则，以Source Insight独特的不等行高的设计，大文件的整体行高计算和显示就会是一个棘手的问题。另外SlickEdit的Slick-C，和Emacs的Lisp是比较独特的，几乎所有的功能都是用Slick-C，或者Lisp实现的，应该算是可扩展性最好的IDE设计之一。
只是Source Insight、SlickEdit、UltraEdit、Textmate、EmEditor、Visual Assist等都有商业赢利支撑，而Eclipse、NetBean等虽开源免费，但背后也都有IBM、Sun等大型技术公司做支撑，相比较之下，开源且免费的Scintilla即便相关的项目众多，几乎占据了开源编辑器项目的半壁江山，但如果所有的项目都只是提需求，缺陷，和等待使用，那么仅靠Neil一个开发者而言，虽然Scintilla已经做得足够好了，也因坚持了近十年的不断奋斗也让人由衷感慨和钦佩，但如果Scintilla想做得更好，实在将是很艰难的前行。
一时感慨，写得多了，希望对于关注或采用Scintilla的项目，以及致力于自行编写编辑器的能有所用。&&&&
&re: 编辑器制作之tab trigger
@megax
字数限制这么厉害啊，拆成三份才算完：（&&&&
&re: 编辑器制作之tab trigger
@megax
再补充一点的是，Snippet自身还可以使用正则实现镜像文本、字符大小写转换（主要是来自于Perl的正则语法\U）等功能，这些Oniguruma支持并不完善，需要自行实现，另外通过自定义一些标签或脚本，可以扩展出更多的、更强大的功能，TextMate的在线帮助中有部分提及，可以自行查阅。
另外需要提一个疑惑的是：既然使用了Oniguruma正则库，Oniguruma使用文本方式匹配时，其算法就是BM算法，已然很快，实在没有必要再编写BM算法了。那又为何在2008年8月之“MegaxEdit开发最新状况”中要自行开发BM或KMP算法呢？&&&&
&re: 编辑器制作之tab trigger
看到TextMate的Manual中关于Bundles的介绍（Tab Triggers只是其中一种应用），发现它的用户可定制性确实很强而方便，具体怎么样，看来得专门弄个实际环境体验一下才行了。&&&&
&re: 编辑器制作之tab trigger
看到这里，我只有说太精彩了！相见恨晚啊。一直没找到专注编辑器开发的地方，结果在这里...HuaHope
是哪位大牛呢？膜拜膜拜！昨晚从MissDeer那里看到了HuaHope绚烂的回复，特意拷贝到手机上以备随时翻阅。这里看到更为完整版的了，哈哈。希望博主或HuaHope提供更多的编辑器相关资源，有时间好好研究下。我对Snippet功能很渴求，在vim、scite里都想用，真希望以后定制个标准，编辑器统统都要原生支持Snippet，哈哈。&&&&