作者: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的,编辑器多半是最最常用的工作或学习的不可或缺的工具。因此如果拥有一套美观的默认外观对于用户使用也是很有用的,毕竟爱美之心人皆有之。
编辑器杂谈
最新推荐文章于 2024-02-18 15:30:28 发布