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

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

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

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

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

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

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

其它:

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

本人確實沒有MAC，找了幾個GIF圖片還有E和intype試用了一下，看見它們都叫bundle，于是誤以為這個在Textmate上也叫bundle.

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

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

本人比較懶，能不寫就盡量不寫，至于想要自行寫B(tài)M算法，主要是編輯器數(shù)據(jù)結(jié)構(gòu)問題。不過現(xiàn)在這個問題已經(jīng)不存在了，因為舍掉了多行匹配能力（即一段文本（含有換行符）可以跨行匹配）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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