編輯器雜談(轉(zhuǎn)載）+點(diǎn)評(píng)

點(diǎn)評(píng)：
Scintilla：     目前Scintilla有一統(tǒng)江湖的趨勢(shì)。只要是新開發(fā)的軟件工具能夠用到高級(jí)編輯器的地方基本上就會(huì)用它了。的確Scintilla為一些開發(fā)提供了便利，但是，是不是也阻礙了編輯器發(fā)展的進(jìn)程啊？沒(méi)人愿意開發(fā)了，還會(huì)有進(jìn)步嘛？所以說(shuō)，有時(shí)候開源并不一定是好事，你開源開的不好就罷了，開的好了，就會(huì)擠掉很多優(yōu)秀的共享軟件，以至于沒(méi)人來(lái)做這項(xiàng)了。
另外Scintilla的出現(xiàn)導(dǎo)致同質(zhì)化非常嚴(yán)重，個(gè)個(gè)都長(zhǎng)的差不多，操作也差不多，體現(xiàn)不出特點(diǎn)，這個(gè)HuaHope的雜談中有描述。如果一個(gè)編輯器要定位于一個(gè)專業(yè)文本編輯軟件，比如現(xiàn)在的Editplus, UlrtaEdit那樣，我覺(jué)得還是不要采用Scintilla的較好，當(dāng)然如果像Code：Blocks定位于IDE，采用Scintilla就是更快更好的選擇了。坦白的說(shuō)，開發(fā)高性能多用途編輯器難度是很高的。

Style：    這個(gè)是我糾結(jié)很長(zhǎng)時(shí)間的一個(gè)東西，在幾年前，我一直是用的動(dòng)態(tài)渲染本屏文本。因?yàn)橐粋€(gè)屏幕上顯示的非常少，所以效率不錯(cuò)。但是也帶來(lái)一些不便。比如括號(hào)匹配時(shí)，就需要重新進(jìn)行分析，否則你不知道該括號(hào)是在注釋中，還是在字符串中，還是真正我們需要的括號(hào)。再比如，現(xiàn)在有些編輯器帶的功能，當(dāng)鼠標(biāo)移動(dòng)到Email，URL之類的時(shí)候，會(huì)出現(xiàn)動(dòng)作，如果采用動(dòng)態(tài)渲染，那么就會(huì)看到CPU明顯的上升。當(dāng)然，也可以再采用一些措施，只存儲(chǔ)當(dāng)前屏幕的Style。但是這會(huì)使得編輯器的架構(gòu)非常的復(fù)雜、繁瑣，以至于我最后都不想去做了。所以為每一個(gè)字符存儲(chǔ)一個(gè)Style（CHAR），是最好的選擇。至此你會(huì)發(fā)現(xiàn)，世界清靜了，代碼漂亮了，但是內(nèi)存也浪費(fèi)了最多一倍(Unicode:0.5倍文本, 其它:最多一倍).有了Style之后，很多事情都好辦了，比如前文提到的括號(hào)匹配，鼠標(biāo)動(dòng)作等。不過(guò)Style應(yīng)該是個(gè)可選功能，在不需要的時(shí)候我們可以對(duì)它關(guān)掉，關(guān)掉的時(shí)候，去掉其它高級(jí)功能支持,MegxEdit已實(shí)現(xiàn)。因?yàn)槊總€(gè)CHAR有8位，我拿出了6位存儲(chǔ)Style,剩下2為用來(lái)標(biāo)記特殊用途，所以可以組合出很好的效果，和Scintilla差不多。

Lexer:     這也是一個(gè)難點(diǎn)，難點(diǎn)不在于寫，而是在于如何和編輯器組合。我最初采用的算法是渲染本屏的文本，存儲(chǔ)該行最后的狀態(tài)。當(dāng)用戶滾動(dòng)的時(shí)候，判斷滾動(dòng)時(shí)的可見(jiàn)行，從該行開始分析。猛一看，這么做太完美了，當(dāng)我費(fèi)了九年二虎之力做完之后，我發(fā)現(xiàn)我做了無(wú)用功。這么做只適合查看文本，但不適合編輯器文本，如果你編輯了文本，在滾動(dòng)的話，同時(shí)屏幕下方都未被分析過(guò)的話，就會(huì)有明顯的延遲了。另外你也判斷不出屏幕下方是否被分析過(guò)，所以最后拋棄。
   所以最后的策略：從用戶輸入點(diǎn)，開始分析，直到下一行是狀態(tài)和本行一致（僅限多行注釋，多行字符串，子語(yǔ)言）。有人會(huì)說(shuō)，每編輯一次都要這么做，豈不是很浪費(fèi)CPU啊？不是這樣的，我告訴你，Editplus, EMEditor, Scintilla都是這么做的。所以也就出現(xiàn)了HuaHope提到的那種情況：如果一個(gè)C++文本很大，并且只是變量定義之類的，不含有任何多行注釋,那么你在開頭輸入/*的話，現(xiàn)在市面上的編輯器(EditPlus, EMEditor, UltraEdit)都會(huì)有延遲。在這一點(diǎn)上Editplus做的較好，MegaxEdit的性能在EditPlus,he EmEditor之間, EmEditor <= MegaxEdit <= EditPlus，其它不再點(diǎn)評(píng)，基本會(huì)假死。
   在現(xiàn)代的CPU+內(nèi)存下，經(jīng)過(guò)我測(cè)試，打開173萬(wàn)行c++文件進(jìn)行括號(hào)匹配，插入字符，Lex分析的話，用戶基本不會(huì)察覺(jué)有明顯延遲。

Unicode:     Editplus、EMEditor和其它的編輯器的內(nèi)核均是UTF16的，MegaxEdit也是。所以如果你打開一個(gè)1M的ANSII文本的話，那么實(shí)際最少使用2M文本+1MStyle=最少3M內(nèi)存。是不是很浪費(fèi)內(nèi)存啊。且聽(tīng)我分析。UTF16內(nèi)核的顯著優(yōu)點(diǎn)是極大極大極大極大的簡(jiǎn)化了開發(fā)，而且完美支持各種字體，即使你現(xiàn)在的文件是CP932，你也可以輸入日文韓文中文，而不會(huì)出現(xiàn)亂碼。至于浪費(fèi)內(nèi)存，在windows操作系統(tǒng)上，申請(qǐng)大塊內(nèi)存談不上浪費(fèi)不浪費(fèi)。真正浪費(fèi)內(nèi)存的地方是UndoRedo數(shù)據(jù)結(jié)構(gòu)和一些文本操作。另外還有一個(gè)內(nèi)存消耗大戶，那就是行信息。為了解決這些真正的，看似不起眼的內(nèi)存消耗,MegaxEdit采用了一個(gè)非常精巧的MemPool,參考自Loki,在一定程度上緩解了這些問(wèn)題。不過(guò)即使如此，在1G的CPU上不建議編輯器超過(guò)200M的文本。
   如果不采用UTF16內(nèi)核，還有一種不錯(cuò)的方案，也就是MBCS方案，這個(gè)我實(shí)現(xiàn)過(guò)，但是被我拋棄了。原因是代碼丑陋。方案如下：文件的存儲(chǔ)仍然采用該文件的物理形式，也就是直接讀取到內(nèi)存上。在顯示的時(shí)候動(dòng)態(tài)轉(zhuǎn)化成Unicode.相關(guān)的函數(shù)有CharNext, CharPrev和MB2CS,CS2MB之類的。這么做的話幾乎可以達(dá)到和UTF16一模一樣的效果，只是插入文本的時(shí)候，同樣要轉(zhuǎn)換，如果插入的文本非該文本的codepage，很顯然會(huì)亂碼。據(jù)我猜測(cè), 日本的秀丸似乎是這么做的。秀丸雖然不支持Unicode，但是可以強(qiáng)制Codepage，KeepContent來(lái)實(shí)現(xiàn)。
   關(guān)于UTF8，其實(shí)UTF8也可以看成MBCS。因?yàn)閁TF8是不定長(zhǎng)的，所以某些操作非常蹩腳，而且讀取文件的時(shí)候需要一定程度的轉(zhuǎn)換，非常的麻煩。
   從平均性能和操作簡(jiǎn)便性上來(lái)說(shuō)，沒(méi)有比UTF16更棒的了。但是UTF16有個(gè)很大的缺點(diǎn)，并不是內(nèi)存占用。而是它無(wú)法原原本本反向操作。比如你用Editplus讀取一個(gè)EXE，指定codepage為932，不作修改，直接保存，那么保存后的文件和原來(lái)的EXE是肯定不一樣的。因?yàn)樯婕暗阶址成涞膯?wèn)題，這是硬傷，無(wú)解決方案。但是，我想不會(huì)有人用文本編輯器編輯器非文本文件吧，所以也無(wú)傷大雅。另外，還有一個(gè)硬傷，現(xiàn)在有了UTF32了，到時(shí)候UTF16就不夠用了，呵呵，也許只有UTF8變長(zhǎng)字節(jié)能支持了。

大文件支持：    呵呵，這是個(gè)很有意思的問(wèn)題，關(guān)鍵是什么叫做大文件。在MegaxEdit上的定義是，文本的大小超過(guò)100M, 文件行數(shù)超過(guò)100萬(wàn)，叫可以叫做大文件了。注意這兒有個(gè)文件行數(shù)限制。如果一個(gè)文本除了換行什么都不含有的話，行數(shù)超過(guò)100萬(wàn)，就會(huì)讓很多編輯器反映遲鈍了。在此吹一下，MegaxEdit還是不錯(cuò)的，性能剛剛的。
    高性能多用途的文本編輯器要考慮的事情非常多，對(duì)于大文件是不可能支持很完美的，甚至直接不支持。所以糾結(jié)于大文件是否支持的好，有點(diǎn)舍本逐末了。曾經(jīng)我就在這點(diǎn)上浪費(fèi)了很多青春。
   不過(guò)我仍然對(duì)大文件處理頗有心得。最投機(jī)取巧的方法就是EmEditor現(xiàn)在采用的那樣，分段映射。不管你多大，我每次只讀取一點(diǎn)。修改的時(shí)候直接在原偏移處，插入修改的代碼即可。如果這么做的話，任何一個(gè)編輯器通過(guò)插件都可以實(shí)現(xiàn)。比較好的做法是采用Piece Table，在此不詳述。

正則表達(dá)式：   說(shuō)實(shí)話，本人自動(dòng)機(jī)學(xué)的很爛。我能寫出一個(gè)正則庫(kù)，但是效率估計(jì)連我都不想用。我最初的目的是做成Lex的那樣，一個(gè)正則式映射一個(gè)狀態(tài)。直接配置，實(shí)現(xiàn)語(yǔ)法加亮。可惜，最后因本人功力有限，放棄。最后采用了日本的鬼車c++ wrapper，最近更新成了5.9.2. 我以前看過(guò)它的日文Help，記得是不支持嵌套的,多謝HuaHope提醒，回頭好好研究研究。如果支持嵌套，那么HotText就支持嵌套變量了。但是MegaxEdit仍然堅(jiān)持變量要定義后使用，因?yàn)榻馕鍪∈隆?br>    在此提一下鬼車，這是一個(gè)很牛X的正則庫(kù)，性能頗高，而且支持各種Encoding，將來(lái)我的多文件正則查找就靠它了。鬼車和Ruby結(jié)合比較緊密，支持好幾種mode，本人研究也不深，希望有志者仔細(xì)研究研究。這兒有個(gè)很不錯(cuò)的c++ wrapper: http://homepage3.nifty.com/k-takata/mysoft/bregonig.html

其它:

>>不過(guò)文中有幾處小錯(cuò)還是需要指出，估計(jì)Megax是不是沒(méi)有蘋果機(jī)器實(shí)際試用和深入研究過(guò)Textmate，所以不太清楚？

本人確實(shí)沒(méi)有MAC，找了幾個(gè)GIF圖片還有E和intype試用了一下，看見(jiàn)它們都叫bundle，于是誤以為這個(gè)在Textmate上也叫bundle.

>>Megax在東京呆了這么多年，即便 英文的幫助沒(méi)注意，日文的幫助也應(yīng)該至少讀一遍的。
你咋知道我在鬼子地方混過(guò)?這都能調(diào)查清楚。O(∩_∩)O哈哈~

>>另外需要提一個(gè)疑惑的是：既然使用了Oniguruma正則庫(kù)，Oniguruma使用文本方式匹配時(shí)，其算法就是BM算法，已然很快，實(shí)在沒(méi)有必要再編 寫B(tài)M算法了。那又為何在2008年8月之“MegaxEdit開發(fā)最新?tīng)顩r”中要自行開發(fā)BM或KMP算法呢？

本人比較懶，能不寫就盡量不寫，至于想要自行寫B(tài)M算法，主要是編輯器數(shù)據(jù)結(jié)構(gòu)問(wèn)題。不過(guò)現(xiàn)在這個(gè)問(wèn)題已經(jīng)不存在了，因?yàn)樯岬袅硕嘈衅ヅ淠芰Γ匆欢挝谋荆ê袚Q行符）可以跨行匹配）。

非常感謝含金量如此高的評(píng)論。拋磚引玉，結(jié)果釣了塊鉆石。

================以下是轉(zhuǎn)載========================
作者：HuaHope
    Scintilla的相關(guān)項(xiàng)目很多，官方網(wǎng)站的related中就列舉了相當(dāng)多的。只是恰如有次見(jiàn)到一個(gè)評(píng)論中說(shuō)的，自從有了 Scintilla，幾乎大多數(shù)的編輯器都很少自己編寫“編輯器”了，完全是加個(gè)外殼，當(dāng)然編輯器控件SynEdit(delphi)、CodeMax等 也功不可沒(méi)。

    就Scite_ru、Scite Latex IDE而言，其實(shí)并不算是出眾的Scintilla相關(guān)項(xiàng)目，而ScintillaLua雖然是這里看到了才知道新有了這個(gè)項(xiàng)目，也剛?cè)ハ螺d了（可惜 zip的解壓失敗，就下載的tgz的），但只是看看配置文件就知道了，其也只不過(guò)是Mitchell Foral的一個(gè)副產(chǎn)品，之前Mitchell Foral就有Scite Tools和Scite St，再加上后來(lái)的Textadept，這幾個(gè)都是差不多的實(shí)現(xiàn)，除了補(bǔ)足SciTE的動(dòng)態(tài)著色之外，還有一個(gè)snippet功能，不過(guò)也許 ScintillaLua可能獨(dú)立后實(shí)現(xiàn)的比以前更完善吧，沒(méi)有看代碼，但是lexer配置倒是豐富了很多，終于幾乎實(shí)現(xiàn)了Scintilla的所有支持 語(yǔ)言，另外一個(gè)最大的改進(jìn)就是許可證終于換成了BSD，比Scite Tools的LGPL要更開放些，以至于SciTE_ru最新的版本就以及迫不及待地整合了ScintillaLua，實(shí)現(xiàn)了外部lexer的支持。不過(guò) 從設(shè)計(jì)角度而言，Lexer采用外掛的lua腳本，處理能力畢竟有限，雖然使用llpeg靈活性增強(qiáng)了，但是效能無(wú)疑更低了，即便是luajit，估計(jì)也 無(wú)法對(duì)付稍大一點(diǎn)的文件。Scintilla比較好的項(xiàng)目，F(xiàn)ilerx算是不錯(cuò)，可惜很久就不更新了。其余的，就編輯器而言，都沒(méi)能走出 Scintilla的限制，也自然更難超越Scintilla自身的光環(huán)。

    其實(shí)國(guó)內(nèi)基于Scintilla的項(xiàng)目也很多的，但真正自己寫編輯器的也有，比如已經(jīng)商業(yè)化的Aptedit，還有MegaxEdit 等，MegaxEdit的博客中講了一些編輯器實(shí)現(xiàn)技術(shù)，比如折疊等，和Scintilla實(shí)現(xiàn)是類似的，只是很可惜，由于沒(méi)有實(shí)物，所以無(wú)法評(píng)測(cè)其功能 和性能，不過(guò)雖然上面說(shuō)大多數(shù)編輯器完全拿來(lái)義不好，但是MegaxEdit完全自己寫，甚至字符串查找KMP算法也自己實(shí)現(xiàn)，實(shí)在也太過(guò)于自力更生，看 日志好像還自己實(shí)現(xiàn)了可配置的狀態(tài)機(jī)，距離正則庫(kù)也差不遠(yuǎn)了，只不知道正則庫(kù)是否也自己寫完了：）Megax還曾經(jīng)到FlexEdit網(wǎng)站評(píng)論過(guò)，雖然指 出沒(méi)有突出優(yōu)勢(shì)的缺點(diǎn)也不算錯(cuò)，但從其日志上描述的技術(shù)思想中感覺(jué)塊著色算法雖然比Scintilla的要好，但是還是不夠完善的，比如不允許循環(huán)嵌套語(yǔ) 言，其實(shí)這個(gè)限制并不應(yīng)存在，除非刻意的構(gòu)造，否則幾乎所有的文件中語(yǔ)言再怎么嵌套都是有限的，也是可以分析著色的。另至于嵌套只允許4個(gè)子語(yǔ)言，對(duì)于 html而言就未必夠用，而且如果不獨(dú)立線程，即便是塊著色速度對(duì)于10萬(wàn)行以上的大文件也依然很慢，不過(guò)Megax從09年2月就消失了，一直到這個(gè)月 才又冒出來(lái)更新日志，感覺(jué)依然對(duì)lex很糾結(jié)，估計(jì)還有一段路要走。當(dāng)然還有MadEdit，也是很不錯(cuò)的，16進(jìn)制和內(nèi)碼做得很好，只是大文件處理能力 有限，界面也不夠美觀。至于國(guó)人的flexedit、notepad++等，也多半只是加個(gè)殼而已。沒(méi)有太多需要說(shuō)的，Notepad++的插件系統(tǒng)倒是 不錯(cuò)，現(xiàn)在的插件也非常的多，只是其中很多沒(méi)有實(shí)現(xiàn)界面的插件并沒(méi)有太多的必要，如果Notepad++實(shí)現(xiàn)ScitTE中的lua腳本擴(kuò)展，編寫腳本即 可擴(kuò)展類似的功能，實(shí)在沒(méi)有必要做成dll，從一種擴(kuò)展走向另一種封閉，只是沒(méi)有深入研究過(guò)其插件系統(tǒng)，感覺(jué)整體設(shè)計(jì)還是不錯(cuò)的，不過(guò)距離幾乎完全插件化 的Eclipse估計(jì)還是有所差距。

    而國(guó)外的自己寫編輯器模塊的就要多一些，比如e texteditor，intype（早期是自己修改的Scintilla，后來(lái)好像是覺(jué)得Scintilla不夠好，重新實(shí)現(xiàn)了自己 的）,sublime text editor等等，其實(shí)編輯器技術(shù)最難，也是最核心的就只是如何對(duì)內(nèi)存進(jìn)行Gap操作，如果完成了這個(gè)，效率足夠，其余的真的很容 易，Codeproject上有一些相關(guān)的教程，但估計(jì)看完的并不多。至于Komodo、XmlSpy、LuaEdit、Autoit的編輯器、 Adobe的Creative Suite套件中的ExtendScript Toolkit等，由于產(chǎn)品定位不同，直接使用Scintilla的編輯器也無(wú)可厚非。何況Komodo、Adobe都曾對(duì)Scintilla社區(qū)有貢獻(xiàn) 過(guò)代碼，比如Scintilla中的Mac代碼很多都是Adobe貢獻(xiàn)的。

     至于MacOs下的Textmate也是自行實(shí)現(xiàn)的編輯器模塊，不過(guò)沒(méi)有測(cè)試過(guò)大文件性能，MacOs下的開發(fā)有個(gè)很好的優(yōu)點(diǎn)，很多都是蘋果內(nèi)置 實(shí)現(xiàn)了，而且MacOs本身就與腳本相當(dāng)緊密，甚至自帶了tcl、perl等，shell也很好用，所以MacOs下的編輯器都實(shí)現(xiàn)的比較好，比如 BBEditor等，xcode使用起來(lái)也非常方便，不過(guò)很奇怪的是，xcode的snippet、自動(dòng)補(bǔ)全等在輸入代碼后會(huì)用灰色字體將后續(xù)的補(bǔ)全，但 是如果用戶不想要這個(gè)，又會(huì)自動(dòng)清除，重新補(bǔ)全，但實(shí)際使用中感覺(jué)文本晃動(dòng)的不太舒服，尤其是多行補(bǔ)全時(shí)，也許有人喜歡這樣的風(fēng)格吧，不過(guò)也可能有設(shè)置可 以關(guān)掉吧。

    當(dāng)然提到編輯器，不能不提的是Unix下的Vim和Emacs，兩者各有千秋，不過(guò)也有各自的缺點(diǎn)，要不如果過(guò)于完美，憑近乎傳奇的悠久歷史，早 就一統(tǒng)江湖了，呵呵。目前兩者在windows平臺(tái)都還算小眾，另外，兩者設(shè)計(jì)也不是絕對(duì)完美的，比如vim的鍵盤映射，命令的內(nèi)部代碼全部是硬編碼，如 dd刪除行，以及yy等就是判斷是否d或y重復(fù)而實(shí)現(xiàn)的，雖然新命令可以做map，也依然可完全定制鍵盤序列，但是如果代碼實(shí)現(xiàn)能夠?qū)㈡I盤序列與對(duì)應(yīng)功能 任意由用戶綁定，或者內(nèi)部使用表來(lái)綁定鍵盤序列和其默認(rèn)功能，即更靈活些就更好了，這樣修改起來(lái)也很容易就可以改進(jìn)鍵盤綁定，而不是現(xiàn)在功能處理分散在代 碼的各個(gè)地方。UltraEdit沒(méi)什么太多要說(shuō)的，雖然不及Vim和Emacs悠久歷史，但也再過(guò)幾年就開發(fā)了二十年了，足夠長(zhǎng)的時(shí)間，也足夠做很多改 進(jìn)了，事實(shí)也是如此，現(xiàn)在的實(shí)在是太龐大了，一個(gè)編輯器要幾十兆，不過(guò)就功能而言，除了大和全之外，16進(jìn)制還可以，列模式雖然也不錯(cuò)，但對(duì)于東亞等復(fù)雜 文字處理還是不夠完善，至于作為重要特性的大文件處理性能其實(shí)也不好，用臨時(shí)文件時(shí)先要復(fù)制一個(gè)副本導(dǎo)致速度很慢，而且占用大量硬盤，不用，就無(wú)法撤銷編 輯，實(shí)在是兩難。何況現(xiàn)代編輯器的許多理念，如自定義著色Lexer、snippet等，也是很難見(jiàn)到。擴(kuò)展性也不夠好。而就體積而言，同樣龐大的 Emacs就遠(yuǎn)比UltraEdit要強(qiáng)上非常多，可見(jiàn)UltraEdit之臃腫，至于提到的大文件和擴(kuò)展性，EmEditor就很不 錯(cuò)，EmEditor通過(guò)基于內(nèi)存映射的框架實(shí)現(xiàn)了一個(gè)很好的大文件編輯功能，不過(guò)EmEditor很多都依賴于插件，未必是很好的設(shè)計(jì)。如果不像 Eclipse那樣，有眾多的擁蹙開發(fā)插件的話，而只靠開發(fā)者本身開發(fā)的話，插件系統(tǒng)用處并不大。更何況雖然EmEditor的腳本擴(kuò)展做得不錯(cuò)，好像也 實(shí)現(xiàn)了com，但是多數(shù)插件仿佛并不是腳本實(shí)現(xiàn)的，這和樣就無(wú)形增加了第三方開發(fā)難處。開發(fā)Visual Assist可以make money，給EmEditor開發(fā)插件，估計(jì)很少有用戶這么做吧，幸好EmEditor還是賣出了不少錢的，開發(fā)者一直相當(dāng)積極的升級(jí)，一次版本都能發(fā) 幾十個(gè)beta版，現(xiàn)在已經(jīng)是版本9了吧，相對(duì)而言，EmEditor升級(jí)對(duì)于現(xiàn)代編輯器功能的關(guān)注還是不錯(cuò)的，9中就已經(jīng)實(shí)現(xiàn)了snippet，比起 UltraEdit經(jīng)過(guò)15個(gè)版本還停留在Templates模板功能上，每次的升級(jí)只是圍繞著彩色的tab頁(yè)，界面配置的角色化，查找窗口中的單行編輯 框變成多行編輯框，應(yīng)該算是比較上進(jìn)的了，不是說(shuō)UltraEdit做的改進(jìn)不重要，只要是用戶使用到的，都是最重要的功能點(diǎn)，但是核心功能的改進(jìn)更不可 或缺，否則界面做得再好，編輯效率提不高，有什么用呢。說(shuō)了這么多編輯器，也提一下Editplus，雖然功能不算突出，但設(shè)計(jì)的很簡(jiǎn)潔，很中庸型的編輯 器。至于pspad，開發(fā)了很多的功能，甚至包括計(jì)算器，顏色拾取器等，確實(shí)很辛苦，但是依然不夠穩(wěn)定，而且比起同樣是delphi編寫的RJ TextEd來(lái)說(shuō)，功能也并不算豐富，界面也遜色些，其實(shí)delphi的界面庫(kù)很好用，換膚功能也很強(qiáng)，雖然也許換膚對(duì)于編輯器而言過(guò)于花哨，但是只要是 會(huì)接觸和使用到編輯器，而不是只知道記事本和word的，編輯器多半是最最常用的工作或?qū)W習(xí)的不可或缺的工具。因此如果擁有一套美觀的默認(rèn)外觀對(duì)于用戶使 用也是很有用的，畢竟愛(ài)美之心人皆有之。

撇開其他非Scintilla的編輯器不談，就Scintilla編輯器而言，最大的缺點(diǎn)，也是很奇怪的，就是幾乎每個(gè)項(xiàng)目都很少會(huì)修改 Scintilla內(nèi)部，Mitchell Foral的Scite Tools和Scite St、Textadept、Scintillalua算是少有的另類，其余的真的很難看到做較大功能改進(jìn)的，也許為了升級(jí)更新編輯器模塊方便，甚至靜態(tài)編 譯的都很少，一律的動(dòng)態(tài)鏈接，幾乎都是完全的拿來(lái)主義。說(shuō)實(shí)話，如果編輯功能只是工程的一部分，那也符合重用的開發(fā)理念，但很多工程本身就是開發(fā)編輯器， 也一味的用而不改進(jìn)核心功能，不僅使自身無(wú)法提高層次，不利于Scintilla發(fā)展，更使得現(xiàn)在大多數(shù)Scintilla同質(zhì)化非常嚴(yán)重，譬 如，Scintilla的列模式幾乎每個(gè)項(xiàng)目都在期待，但是由于Neil一直很難決定如何很好的實(shí)現(xiàn)virtual space，所以所有的相關(guān)項(xiàng)目的列模式為人詬病已經(jīng)很多年，直到2.0中實(shí)現(xiàn)了多選區(qū)編輯和virtual space功能才算是了卻了幾年來(lái)的心愿，而且就目前而言，列模式還實(shí)現(xiàn)得并不完善，比如列模式下的粘貼文本就無(wú)法像UltraEdit一樣粘貼到每一 行。
不過(guò)1.76之后的代碼就很少跟蹤了，也沒(méi)有去看這個(gè)新功能代碼如何實(shí)現(xiàn)的，其實(shí)virtual space和列模式功能要實(shí)現(xiàn)很簡(jiǎn)單，只要在原先選區(qū)的Anchor和current基礎(chǔ)上增加virtual Anchor和virtual current即可。另外每個(gè)項(xiàng)目都知道Scintilla內(nèi)存消耗是文本自身的兩倍，僅僅是為了實(shí)現(xiàn)style，Neil在實(shí)驗(yàn)項(xiàng)目中 SinkWorld雖然對(duì)此作出了改進(jìn)，但是SinkWorld進(jìn)展實(shí)在非常緩慢，類似于Scintilla與SciTE，展示SinkWorld的 Tentacle 也很久沒(méi)有更新了。而且SinkWorld中的改進(jìn)是針對(duì)于Scintilla中style的8個(gè)bit位128種style無(wú)法充分支持html這種可 嵌入子語(yǔ)言類型很多的擴(kuò)展型語(yǔ)言的，要實(shí)現(xiàn)的是動(dòng)態(tài)長(zhǎng)度的Style，這樣必然會(huì)帶來(lái)更嚴(yán)重的內(nèi)存問(wèn)題，其實(shí)就內(nèi)存而言，打開相同的文件，Vim消耗的內(nèi) 存是相對(duì)而言比較少的，基本上比實(shí)際文本多一些，而其他的編輯器大多也是內(nèi)存消耗很多，甚至有三倍于文本自身的，但其實(shí)內(nèi)存問(wèn)題并不必要用現(xiàn)在的 style實(shí)現(xiàn)方式的，動(dòng)態(tài)數(shù)組是一個(gè)更好的方式，不僅可以做到內(nèi)存占用幾乎與文本自身大小接近，而且對(duì)于識(shí)別同一style的起始結(jié)束和結(jié)束都是很有益 處的，復(fù)雜度甚至可以做到常量，而不是現(xiàn)在的線性，需要逐個(gè)byte的去比對(duì)搜索，這點(diǎn)對(duì)于基于代碼做分析，比如識(shí)別注釋、字符串等塊狀文本有很重要的意 義。
當(dāng)然，Scintilla目前最大的弱勢(shì)還是在于正則庫(kù)，Regex實(shí)在是一個(gè)過(guò)于簡(jiǎn)單的正則引擎，雖然Scintilla在1.77版本中就實(shí)現(xiàn)了 正則引擎的外接口，相關(guān)項(xiàng)目，如Programmer's Notepad也已經(jīng)實(shí)現(xiàn)了使用Pcre和Xpressive分別用于Scintilla內(nèi)部和配置的正則匹配，但是多半還是需要針對(duì)各個(gè)引擎庫(kù)寫迭代器 的，這樣就不免又造成了一定的門檻，使得現(xiàn)在大多數(shù)項(xiàng)目依然使用內(nèi)置的功能很弱的正則庫(kù)。而沒(méi)有一個(gè)優(yōu)秀的正則庫(kù)作為支撐，就很難實(shí)現(xiàn)自由度很高的自動(dòng)縮 進(jìn)、函數(shù)識(shí)別等，更重要的，Lexer就無(wú)法做成可配置。用戶自由的實(shí)現(xiàn)如vim、emacs、textmate那樣編寫lexer擴(kuò)展就無(wú)法成為可能。 而缺少這些，對(duì)于現(xiàn)代的編輯器功能而言，不免是一個(gè)很大的遺憾和功能劣勢(shì)。
除此以外，對(duì)于大文件的支持也是Scintilla的弱勢(shì)，由于內(nèi)部的設(shè)計(jì)導(dǎo)致 的雙倍內(nèi)存問(wèn)題，使得大文件支持更為捉衿見(jiàn)肘，相關(guān)的一些功能，比如括號(hào)對(duì)匹配高亮，以目前的SciTE內(nèi)部實(shí)現(xiàn)是搜索全部文本，這顯然在大文件時(shí)會(huì)導(dǎo)致 界面假死，而Notepad++則彌補(bǔ)了這個(gè)缺陷，將搜索限定在上下搜索2000行而已，但這對(duì)于大文件又顯然是不夠的。諸如此類的功能，對(duì)于大文件而言 便不免會(huì)有所缺失，不過(guò)Neil很早就宣稱，Scintilla并不是為大文件設(shè)計(jì)的，所以也無(wú)可厚非。何況大文件的需求比較特殊，并不能完全做到統(tǒng)一， 也許Neil除了認(rèn)為難以實(shí)現(xiàn)之外，還考慮到了大文件操作與系統(tǒng)是緊密相連的，比如windows的內(nèi)存映射，其他平臺(tái)的實(shí)現(xiàn)就不盡相同，因此嚴(yán)格意義 上，就Scintilla不與具體系統(tǒng)捆綁的設(shè)計(jì)目標(biāo)來(lái)說(shuō)，這并不是Scintilla遺漏的功能，實(shí)際上，從某種意義而言，Scintilla已經(jīng)提供 了很好的框架，足以支撐外部項(xiàng)目使用系統(tǒng)函數(shù)和算法更好的處理大文件，不過(guò)所有的項(xiàng)目鮮有見(jiàn)到實(shí)現(xiàn)了大文件操作的，包括最流行的項(xiàng)目Notepad++。 當(dāng)然大文件本身就是很難做處理的，即便是宣稱大文件處理比較好的EmEditor，打開普通的非著色文件還好，但一旦遇到著色的如cpp文件，也一樣會(huì)很 痛苦，因?yàn)橹切枰闅v每一個(gè)字符并采集屬性的，因無(wú)法見(jiàn)到EmEditor的Lexer代碼，不知道如何實(shí)現(xiàn)的。但是要解決著色問(wèn)題，前提必然是 Lexer線程獨(dú)立，而非Scintilla現(xiàn)在的單線程，雖然Scintilla內(nèi)部設(shè)計(jì)了一些位置信息，可以接續(xù)著色等，但對(duì)于大文檔，依然會(huì)有明顯 的延遲。Vim要好些，可惜也沒(méi)有去研究過(guò)其Lexer代碼。上文提到的Megax的分塊著色是一個(gè)好的解決方案，但是多線程依然是最終解決的不可或缺 的，其實(shí)Scintilla Maillist中很早就幾次提過(guò)多線程著色，但是Neil認(rèn)為難度很大，也沒(méi)有人提出可行的方案，也就不了了之了。
與大文件類似的，缺失的還有全面支持 UTF8，和16進(jìn)制，vim和Emacs等早已經(jīng)實(shí)現(xiàn)了內(nèi)部完整支持Unicode，當(dāng)然實(shí)際內(nèi)碼是UTF8，因?yàn)閷?duì)于許多字符集而言，Utf8比 Utf16等編碼方式要節(jié)省內(nèi)存，而Scintilla則由于擴(kuò)展性，采取設(shè)置內(nèi)碼方式，雖然也可以支持UTF8，但是兼容多內(nèi)碼的設(shè)計(jì)帶來(lái)了很多的效率 問(wèn)題，比如查找時(shí)，對(duì)于MBCS，就需要判斷當(dāng)前字符是否是leading字符，這樣很顯然會(huì)非常慢，這從SciTE設(shè)置內(nèi)碼為CP936等代碼頁(yè)后的搜 索就可以很明顯的看出與其他編輯器的速度差距，而且支持單一的UTF8可以更好的識(shí)別文本，比如中文的書名號(hào)配對(duì)《》，這是多內(nèi)碼設(shè)計(jì)所無(wú)法實(shí)現(xiàn)的，因?yàn)?項(xiàng)目無(wú)法對(duì)每一種代碼頁(yè)都做分析，做出特定的表來(lái)識(shí)別，不過(guò)這個(gè)錯(cuò)不完全在Scintilla，外部項(xiàng)目本身可以彌補(bǔ)這些缺陷，可惜從開源的一些編輯器實(shí) 現(xiàn)上看，并沒(méi)有編輯器如此做。
至于16進(jìn)制，UltraEdit實(shí)現(xiàn)的比較好，雖然一些編輯器項(xiàng)目也實(shí)現(xiàn)了16進(jìn)制，比如FlexEdit、 Notepad++、Scite_RU等，但是FlexEdit是另外寫的16進(jìn)制編輯模塊，不是用的Scintilla，Notepad++也是一 樣，HexEditor插件也是另外實(shí)現(xiàn)的基于樹形列表Treelist的16進(jìn)制編輯控件，而SciTE_Ru雖然是通過(guò)lua腳本實(shí)現(xiàn)了原生的 Scintilla十六進(jìn)制編輯，但是類似于Dos時(shí)的小窗口編輯實(shí)現(xiàn)的并不算好。很奇怪的是，1.78版本中實(shí)現(xiàn)的兩個(gè)主要新特性之一的文本邊欄 Text margin就完全可以很好的實(shí)現(xiàn)16進(jìn)制編輯時(shí)的偏移量顯示，但是依然還是見(jiàn)不到有項(xiàng)目基于此自行實(shí)現(xiàn)的16進(jìn)制編輯功能，也許一樣要等到 Scintilla完全實(shí)現(xiàn)內(nèi)置16進(jìn)制編輯才會(huì)普及吧。至于1.78中添加的另一個(gè)新特性注釋行Annotation lines，很類似于xcode中設(shè)計(jì)的出錯(cuò)顯示，不過(guò)也許visual studio等windows開發(fā)環(huán)境習(xí)慣于將錯(cuò)誤輸出到Output窗口，而只有要顯示匯編時(shí)才混合代碼和匯編一起顯示，所以Annotation lines也是應(yīng)用寥寥，平心而論，Scintilla就編輯功能的覆蓋廣度已經(jīng)做得比較完備了，許多功能并不弱于vim、Emacs等超級(jí)編輯器，但是 問(wèn)題在于各項(xiàng)目組合基礎(chǔ)功能之后的深度還不夠，以至同質(zhì)化嚴(yán)重的同時(shí)，各項(xiàng)目也功能平平，比如自動(dòng)縮進(jìn)，vim實(shí)現(xiàn)了四種縮進(jìn)，auto、smart、 c、以及indentexpr，而emacs則實(shí)現(xiàn)了gnu、java、linux、python、user等多種成熟的縮進(jìn)風(fēng)格，提過(guò)組合，在vim和 emacs中幾乎常見(jiàn)的縮進(jìn)風(fēng)格都很容易實(shí)現(xiàn)。而SciTE實(shí)現(xiàn)了簡(jiǎn)單的自動(dòng)縮進(jìn)后，大多數(shù)基本沿用，因此縮進(jìn)都不夠智能，而Notepad++的插件 NppAutoIndent則從一定程度上改進(jìn)了Notepad++的自動(dòng)縮進(jìn)，可見(jiàn)自動(dòng)縮進(jìn)并非是Scintilla不能支持，而是大多數(shù)項(xiàng)目設(shè)計(jì)使用 不當(dāng)。
當(dāng)然SciTE還展示了lua腳本擴(kuò)展，以及提過(guò)windows的消息擴(kuò)展等，如Filerx就是使用外部SendMessage來(lái)操作 SciTE，效果很好，可以錄制和重放操作，對(duì)于文本編輯器而言，lua腳本使用SciTe的庫(kù)函數(shù)接口已經(jīng)足夠?qū)崿F(xiàn)絕大多數(shù)文本功能擴(kuò)展。但可惜的是， 大多數(shù)項(xiàng)目沒(méi)能很好的繼承SciTE這種良好的擴(kuò)展性，大多數(shù)項(xiàng)目沒(méi)有實(shí)現(xiàn)類似的lua系統(tǒng)，就是有擴(kuò)展性也是另起爐灶，如Notepad++自行實(shí)現(xiàn)了 插件系統(tǒng)，固然設(shè)計(jì)的還不錯(cuò)，但卻失去了腳本的靈活，而programmer's notepad等雖也自行實(shí)現(xiàn)了采用python等其他腳本語(yǔ)言的腳本擴(kuò)展，可惜自由度卻還是不如SciTE。當(dāng)然同樣可惜的是，依然有些擴(kuò)展是需要有界 面的，尤其是運(yùn)行時(shí)需要引入?yún)?shù)的，而單純的lua無(wú)法擴(kuò)展界面，lua的幾個(gè)界面庫(kù)如iup，tckUI等也不能很好的擔(dān)當(dāng)大任，使得單純的SciTE 中的lua擴(kuò)展使用并不是特別方便，再加上SciTE本身非界面化的配置不夠友好，導(dǎo)致其用戶并不是很多。至于lua和wxWidgets或者Qt雖然可 以較好的互動(dòng)，但是前提是SciTE不是采用這些庫(kù)開發(fā)的，而即便有項(xiàng)目以這些界面庫(kù)開發(fā)，使用lua來(lái)控制，估計(jì)需要做的事情依然很多，不夠輕量化，也 不符合現(xiàn)在網(wǎng)絡(luò)化的發(fā)展趨勢(shì)。
至于比編輯器更復(fù)雜的IDE，情況也差不多，大多數(shù)IDE現(xiàn)在都是Eclipse化了，另外由于Borland的黯然離開，除了微軟自家的Visual Studio，考慮到跨平臺(tái)，IDE多半用的不是java就是wxWidgets，如另一個(gè)與Eclipse齊名的NetBean也是java實(shí)現(xiàn)的。而 一些小型的IDE，如Code::Blocks、Komodo等，出于開發(fā)方便，最主要的核心組件之一也很少自行開發(fā)，直接使用了Scintilla，其 實(shí)，無(wú)論是從開發(fā)角度還是使用角度而言，編輯器不僅僅是IDE的基礎(chǔ)，也同時(shí)已經(jīng)具備了IDE的初步雛形，尤其是除了少數(shù)幾個(gè)巨型IDE如微軟的 Visual Studio，Sun Java Studio，IBM Rational（基于Eclipse），以及一些CPU廠商，如Intel、Motorola的IDE等，可以有足夠的實(shí)力考慮和實(shí)現(xiàn)包括編譯器、調(diào)試 器、編輯器、版本控制器等各個(gè)組件的設(shè)計(jì)開發(fā)銜接以更好的整合之外，大多數(shù)的IDE基本都是外掛式的，比如掛上GCC，SVN等等，而這些，很多編輯器其 實(shí)也都可以做到，甚至包括外掛調(diào)試器，只是相對(duì)而言，由于設(shè)計(jì)目標(biāo)和定位不同，IDE實(shí)現(xiàn)和整合的功能更多，IDE的插件系統(tǒng)一般也更復(fù)雜也更完善，擴(kuò)展 功能更容易，而這對(duì)于大多數(shù)單兵作戰(zhàn)開發(fā)的編輯器就很少會(huì)充分的考慮到。當(dāng)然類似的還有SlickEdit、UltraEdit Studio，以及以代碼分析著稱的Source Insight等第三方IDE，至于Emacs也可以算是IDE吧，對(duì)于此類IDE，優(yōu)秀的編輯器都一樣是其基礎(chǔ)，不過(guò)就以Source Insight而言，其定位就是編輯代碼文件，因此大文件操作就很少考慮，否則，以Source Insight獨(dú)特的不等行高的設(shè)計(jì)，大文件的整體行高計(jì)算和顯示就會(huì)是一個(gè)棘手的問(wèn)題。另外SlickEdit的Slick-C，和Emacs的 Lisp是比較獨(dú)特的，幾乎所有的功能都是用Slick-C，或者Lisp實(shí)現(xiàn)的，應(yīng)該算是可擴(kuò)展性最好的IDE設(shè)計(jì)之一。

   只是Source Insight、SlickEdit、UltraEdit、Textmate、EmEditor、Visual Assist等都有商業(yè)贏利支撐，而Eclipse、NetBean等雖開源免費(fèi)，但背后也都有IBM、Sun等大型技術(shù)公司做支撐，相比較之下，開源且 免費(fèi)的Scintilla即便相關(guān)的項(xiàng)目眾多，幾乎占據(jù)了開源編輯器項(xiàng)目的半壁江山，但如果所有的項(xiàng)目都只是提需求，缺陷，和等待使用，那么僅靠Neil 一個(gè)開發(fā)者而言，雖然Scintilla已經(jīng)做得足夠好了，也因堅(jiān)持了近十年的不斷奮斗也讓人由衷感慨和欽佩，但如果Scintilla想做得更好，實(shí)在 將是很艱難的前行。
   很高興沒(méi)看到MegaxEdit沒(méi)自行實(shí)現(xiàn)正則庫(kù)，前段時(shí)間在MissDeer的博客中隨手寫的一篇“編輯器雜談”中還提到了這個(gè)，開發(fā)應(yīng)有所為有所不 為，什么都自行實(shí)現(xiàn)且不論是否可以寫得更好，也實(shí)在沒(méi)有必要，當(dāng)然例如Emacs的Richard Stallman樣樣精通的超級(jí)大牛除外。“編輯器雜談”主要是針對(duì)Scintilla系編輯器寫的，也評(píng)論了點(diǎn)現(xiàn)有知名編輯器，隨附在后，希望一點(diǎn)心得 有點(diǎn)小用。

    不過(guò)文中有幾處小錯(cuò)還是需要指出，估計(jì)Megax是不是沒(méi)有蘋果機(jī)器實(shí)際試用和深入研究過(guò)Textmate，所以不太清楚？

其一，Textmate的這個(gè)功能不是Bundle，而是Snippet，Bundle功能比這個(gè)要重要和強(qiáng)勁的多，Bundle構(gòu)建了腳本與編 輯器以及系統(tǒng)的關(guān)聯(lián)，類似于腳本宏，MacOs上腳本體系比Windows要好很多，自帶的腳本也遠(yuǎn)比Windows的JavaScript、 VbScript要豐富，當(dāng)然Windows的Com也異常強(qiáng)大，不過(guò)蘋果在腳本體系的人機(jī)交互上遠(yuǎn)比Windows要好上很多。而Snippet則基本 上就是文本段落輔助完成，其實(shí)Visual Studio里面就有Snippet功能，不過(guò)估計(jì)使用和研究的人更少，畢竟不是很明顯的功能。Vim和Emacs也早有插件，或多或少也實(shí)現(xiàn)了較完整的 Snippet。

其二，Oniguruma正則庫(kù)，也就是鬼車是支持循環(huán)嵌套的，其自帶的幫助中寫得很清楚，而且還舉了實(shí)例，Megax在東京呆了這么多年，即便 英文的幫助沒(méi)注意，日文的幫助也應(yīng)該至少讀一遍的。應(yīng)該說(shuō)，最近流行的正則庫(kù)大多數(shù)都已經(jīng)實(shí)現(xiàn)了嵌套匹配，如腳本語(yǔ)言Perl、PHP、開發(fā)平 臺(tái).Net、Java的正則庫(kù)，以及正則庫(kù)Greta等都是支持嵌套的，這個(gè)在O'Reilly《精通正則表達(dá)式》一書中有詳細(xì)的描述。當(dāng)然1.9.0版 本之后采用Oniguruma的Ruby自然也支持嵌套正則。不過(guò)也正由于Oniguruma合入了Ruby，因此現(xiàn)在Oniguruma的最新代碼已基 本合并入Ruby開發(fā)，可惜的是，Ruby加了很多專有的定義進(jìn)去，使得剝離一個(gè)最新的Oniguruma已經(jīng)很難了。最容易為第三方集成使用的 Oniguruma也許永遠(yuǎn)都定格在5.9.1了吧。

其三，正因?yàn)镺niguruma支持嵌套正則，所以TextMate支持Snippet嵌套變量也就不足為奇了，因?yàn)門extMate的正則庫(kù)正 是Oniguruma的Cocoa移植版本，也許是OgreKit。當(dāng)然由于Textmate商業(yè)軟件的源碼不可見(jiàn)，也不排除TextMate直接使用字 符串函數(shù)進(jìn)行解析，因?yàn)镾nippet本身并不復(fù)雜，純字符串解析也很容易。目前Snippet做的比較完善的除了TextMate，還有Intype一 樣的支持嵌套變量，但是e TextEditor就只能支持簡(jiǎn)單的文本了。

其四，寫偽碼時(shí)最好也要注意語(yǔ)法，strFind.Format( "\$\{%d:(.*?)\}", i ); 肯定編不出正則的，Escape轉(zhuǎn)義字符應(yīng)該寫\\，而不是\，要不然引號(hào)就先使用\轉(zhuǎn)義了，再往下就自然出錯(cuò)。這不是TCL，TCL可以使用{}來(lái)規(guī) 避，而C則不行。

不過(guò)總得來(lái)說(shuō)，基本上Snippet的實(shí)現(xiàn)就是這樣了，不過(guò)依然有兩點(diǎn)需要改進(jìn)，一是變量的順序，其實(shí)沒(méi)有必要規(guī)定順序。當(dāng)然，如果按一次處理一 個(gè)序號(hào)自然會(huì)引入順序問(wèn)題，但是如果一遍先將所有編號(hào)區(qū)域全部找出存儲(chǔ)，并記錄位置信息，再行一次性替換，就可以解決順序問(wèn)題了。其二，Tab鍵并不是一 個(gè)完美的鍵，無(wú)論是TextMate，還是Intype等，都只可以用Tab前進(jìn)，而無(wú)法后退，這是因?yàn)門ab本是就是縮進(jìn)鍵，此處挪作Snippet 用，從而導(dǎo)致一個(gè)鍵二次定義，從用戶角度上而言是不可取的，使得用戶在Snippet過(guò)程中無(wú)法縮進(jìn)，例如復(fù)雜點(diǎn)的段落，自動(dòng)縮進(jìn)不完美的情景下，用戶就 只能退出Snippet再行修改了。因此目前TextMate等多半是在編寫Snippet時(shí)就預(yù)設(shè)好縮進(jìn)，在Snippet時(shí)僅僅依據(jù)上一行進(jìn)行整體縮 進(jìn)，從而一定程度上避免了這個(gè)問(wèn)題。但是也因?yàn)楹茈y做完善，所以Shift-Tab并沒(méi)有用來(lái)實(shí)現(xiàn)Snippet的回跳，依然還是定義為減少縮進(jìn)。這個(gè)問(wèn) 題在 Mitchell Foral 的Scite-Tools中有提及，因此Scite-Tools在Scite的基礎(chǔ)上使用Ruby實(shí)現(xiàn)了Snippet時(shí)，并沒(méi)有使用Tab鍵，而是 Ctrl的組合鍵，這樣就輕松的完成了前進(jìn)和后退，如果TextMate等跳出Tab的圈子，自然一樣可以輕松后退，不過(guò)如果決定權(quán)交到用戶手中也許會(huì)更 好。Mitchell Foral 基于Scite的后來(lái)的最新Mod作品，如TextAdept等，Snippet又用lua重新編寫了。由于Snippet自身就是Ruby或Lua腳本 的便利性，Mitchell的Snippet從某種意義而言應(yīng)該是比TextMate更為強(qiáng)大，因?yàn)榇藭r(shí)Snippet已經(jīng)是具有完備功能的腳本段，有點(diǎn) 類似于Bundle，而不再僅僅是一段字符串了。

    Snippet作為一個(gè)非常便捷的編碼輔助功能，也依然在不斷發(fā)展，自解釋應(yīng)是目前的最新階段，其代表就是Zen Coding，作為快速開發(fā)的典范，類CSS的語(yǔ)法，使得編寫Html等網(wǎng)頁(yè)語(yǔ)言非常迅捷，可惜，其作用域由于語(yǔ)法特殊性，估計(jì)也很難走出Html的編程 范圍了。

一時(shí)感慨，寫得多了，希望對(duì)于關(guān)注或采用Scintilla的項(xiàng)目，以及致力于自行編寫編輯器的能有所用。