摘要: 今天我終于實(shí)現(xiàn)了偉大的智能提示了，真是渾身上下都在發(fā)光啊。這次智能提示的代碼可以在Vczh Library+ 3.0的頁面上看到。我使用了上一篇文章所提到的技術(shù)，在用戶輸入文字的時(shí)候，通過迅速獲得“當(dāng)前編輯語句”的語法樹，再加上舊的“當(dāng)前編輯語句”的作用域?qū)ο螅瑏砼袛嘤脩艟烤固幱谡荽a的什么地方，最后給出正確的提示。
  閱讀全文     隔了兩個(gè)星期才更新，主要是因?yàn)橹坝幸粋€(gè)星期我拿來做了一個(gè)Ribbon的DEMO，將來打算用Ribbon來做IDE。另一個(gè)原因是這次去的的重大突破消耗了我整整一個(gè)星期的時(shí)間來完成，好久沒有遇到這么困難的問題了……

    這次主要解決的問題有兩個(gè)。第一個(gè)是如何從文法生成一個(gè)可以對(duì)付殘缺不全的代碼的語法分析器，當(dāng)然這個(gè)已經(jīng)被很多論文研究過無數(shù)遍了，我就不詳細(xì)解釋了。第二個(gè)是如何高效的進(jìn)行分析。我們知道當(dāng)代碼高達(dá)10000行的時(shí)候，語法分析再怎么快也得花上幾秒鐘時(shí)間（C#寫的，已經(jīng)很快了，何況這段代碼是生成的……）的。但是用戶在按下“->”的時(shí)候根本來不及等你這么幾秒，所以我想到了一個(gè)方法。

    用戶寫代碼的時(shí)候總是會(huì)陷入思考的，這個(gè)時(shí)候后臺(tái)的全文分析會(huì)跟上來，然后標(biāo)記出“當(dāng)前編輯語句”部分。如果你接下來快速輸入，我除了再次啟動(dòng)后臺(tái)的全文分析之外，我還會(huì)針對(duì)用戶的輸入來修改“當(dāng)前編輯語句”的字符串然后針對(duì)這小小的幾行代碼用語法分析產(chǎn)生一個(gè)語句列表。這樣的話UI線程里面的語法分析就快到可以忽略了，而且每隔幾秒鐘后臺(tái)的全文分析就會(huì)趕上然后替換最新結(jié)果。這樣可以保證你在打代碼的時(shí)候有99%的概率我的語義分析可以正常工作。就算不能工作，也就是產(chǎn)生不出那個(gè)下拉列表，一般來說，這種情況只有那些打字的APM超過500的人才會(huì)碰到，正常人是不會(huì)碰到的……

    介紹了原理之后，我就來貼張圖了。不過在我這個(gè)Demo里面你真的輸入10000行代碼還是會(huì)感覺到延遲的，那是因?yàn)槲覟榱苏{(diào)試，在Tree里面每次都會(huì)產(chǎn)生一顆平均十幾萬行的文本表示的全文語法樹，Windows的那個(gè)文本框性能太爛了……

    就貼幾張圖好了，首先是輸入object，然后輸入->，最后輸入member;。寫到->的時(shí)候已經(jīng)出現(xiàn)了NativeXPointerMemberExpression了，下拉列表的所有信息已經(jīng)完全出來了，哇哈哈。




     摘要:     使用了上一篇文章的方法，我已經(jīng)用C#把NativeX語言的語法分析器寫出來了。而且最近把代碼文件重構(gòu)了一遍，刪除掉了原來的實(shí)驗(yàn)性工程，轉(zhuǎn)而重新設(shè)計(jì)了一個(gè)比較合理的工程結(jié)構(gòu)，當(dāng)然還是提交到了Vczh Library++ 3.0的頁面上去了。現(xiàn)在先來看一看給IDE使用的文法哈。現(xiàn)在語法分析器已經(jīng)有兩套了，一套是C++寫的用于開發(fā)NativeX的編譯器的，...  閱讀全文      摘要:     在詞法分析器生成器寫完之后，就要做語法分析器的生成器了。今天完成了生成器的第一個(gè)版本。這個(gè)語法分析器生成器所做的事情就是從一個(gè)C#寫的文法產(chǎn)生出C#寫的該文法對(duì)應(yīng)的語法分析器。在寫文法的時(shí)候你需要提供每一個(gè)文法的返回類型，以及指定每一個(gè)屬性究竟對(duì)應(yīng)著文法的哪一段。為了方便，我提供了預(yù)定義的列表文法和左遞歸文法。當(dāng)然我們知道手寫遞歸下降分析器都是有套路的，用人寫...  閱讀全文      摘要:     詞法分析器生成器終于做好了，因此我又畫了一個(gè)狀態(tài)機(jī)然后生成了一個(gè)詞法分析器，因此開始研究IDE的智能提示的技術(shù)了。智能提示的技術(shù)有幾個(gè)要點(diǎn)，第一個(gè)是無論怎么慢都不能妨礙你打字，第二個(gè)是崩潰了也不能讓IDE關(guān)掉，要重啟分析器。因此我做了一個(gè)小實(shí)驗(yàn)。首先我將NativeX語言的著色器跟詞法分析器都做好了，因此我要做的事情就是在你打字的時(shí)候，用另外一個(gè)線程進(jìn)行詞法分...  閱讀全文      摘要:     休息了大半個(gè)月，沒寫自己的代碼了。國(guó)慶過了，再不為自己寫寫代碼就有負(fù)罪感了。這篇文章所提到的所有工具的代碼都可以在Vczh Library++ 3.0的頁面找到。上一篇文章提到了一個(gè)狀態(tài)機(jī)繪圖工具，直到最近我終于把他的第一個(gè)部分給做好了。現(xiàn)在可以畫圖之后產(chǎn)生一個(gè)可以供這里所描述的高亮控件所使用的著色器了。第一步我們要使用TokenizerBuilder繪制一個(gè)...  閱讀全文     接著上一篇的話題。開發(fā)智能提示首要的問題就是開發(fā)一個(gè)高性能的語法分析器。一個(gè)高性能的語法分析器總是包含一個(gè)高性能的詞法分析器的。本系列的第一篇已經(jīng)提到了用C#和狀態(tài)機(jī)寫著色器對(duì)10萬行代碼進(jìn)行著色只需要半秒。鑒于我們大部分的程序文件都只是幾千行，因此用相同的技術(shù)開發(fā)的詞法分析器顯然可以在幾十毫秒內(nèi)完成對(duì)文件的分析，從而再也不需要擔(dān)心詞法分析器的性能問題了。

    著色器的狀態(tài)機(jī)一般都比詞法分析器的狀態(tài)機(jī)簡(jiǎn)單，因?yàn)槲覀兛偸鞘褂靡粋€(gè)顏色來表達(dá)一些類型的記號(hào)（譬如操作符、數(shù)字和名字一般都用同樣的顏色——黑色）。因此我們每當(dāng)支持一種新語言或者當(dāng)語言升級(jí)的修改IDE的時(shí)候，總是要同時(shí)修改兩個(gè)狀態(tài)機(jī)。手寫狀態(tài)機(jī)是很容易出錯(cuò)的，就如同手寫語法分析器也很容易出錯(cuò)一樣。語法分析器的解決辦法是讓你給文法來生成語法分析器的代碼，因此詞法分析器和著色器也使用類似的方法：給狀態(tài)機(jī)生成代碼。

    目前這個(gè)狀態(tài)機(jī)只做了一半：只能畫狀態(tài)，暫時(shí)還不能指定顏色或者記號(hào)類型。當(dāng)然添加一個(gè)指定顏色的功能是很簡(jiǎn)單的，不過我還需要想一想如何用圖像來表達(dá)，讓狀態(tài)機(jī)顯得更清晰。今天做了一個(gè)晚上搞定了狀態(tài)機(jī)的編輯程序，如圖所示：

    接下來就可以開發(fā)兩個(gè)功能，第一個(gè)是生成著色器的代碼，第二個(gè)是生成詞法分析器的代碼。這樣就可以避免因?yàn)槌绦驅(qū)戝e(cuò)從而省下一大堆調(diào)試的時(shí)間了。     今天來說一下智能提示的初步想法。智能提示需要解決的問題有兩個(gè)。第一個(gè)是迅速知道光標(biāo)位置在與編輯中的代碼相對(duì)應(yīng)的抽象語法樹中的位置。第二個(gè)是把當(dāng)前用戶可以輸入的東西顯示出來并且提供輸入的便利。第一個(gè)問題里面有兩個(gè)小問題，包括用你能達(dá)到的最快速度分析代碼全文組成語法樹并產(chǎn)生scope表，以及智能地在用戶輸入東西的時(shí)候臨時(shí)對(duì)輸入的那一小塊（如何確定塊的區(qū)域，這個(gè)根據(jù)不同的語言以及編輯的不同位置可能需要不同的算法）進(jìn)行重新分析產(chǎn)生一棵小樹。我們總是可以在全文分析沒結(jié)束之前，使用上一次全文分析產(chǎn)生的scope表以及這棵小樹來得到超過99%正確率的上下文。

    那么今天要說的就是如何用C#進(jìn)行高效的全文分析。我們知道全用LALR的話不僅難開發(fā)而且代碼難調(diào)試難測(cè)試難修改，因此就算了。最好調(diào)試的代碼是什么呢，顯然是遞歸下降法寫出來的。其實(shí)代碼本來沒多少層，所以遞歸下降最多也就遞歸十幾層，也不會(huì)太多，總的來說性能還是可以接受的。但是每來一個(gè)語言就用一次遞歸下降還是很慘的。好在.net自帶C#編譯器，我們可以使用parser combinator來生成。關(guān)于什么是combinator，可以參考這里。至于什么是parser combinator，我曾經(jīng)用C++實(shí)現(xiàn)了一個(gè)。

    Parser combinator的好處是我們可以在C#里面把文法直接表達(dá)出來，然后變成一個(gè)語法分析器。不過直接執(zhí)行combinator，性能會(huì)受到很大影響。怎么樣才能把性能降低到跟手寫的差不多呢？.NET給了我們?nèi)N武器，分別是CodeDom、Emit和Linq Expression。我比較傾向于CodeDom，CodeDom可以讓我們寫C#來拼出一顆巨大的代表一個(gè)C#程序的語法樹，然后用自帶的.net編譯器去編譯成dll或者cs文件。因此這個(gè)C#的parser combinator的目的就是要讓我們用最美妙的語法來拼出目標(biāo)語言的文法，最后根據(jù)文發(fā)來產(chǎn)生一份C#語法分析器的代碼。我們可以每次運(yùn)行的時(shí)候都編譯出一個(gè)內(nèi)存的dll，或者直接產(chǎn)生一個(gè)cs文件然后拖進(jìn)我們的工程。

    我目前可能會(huì)采取前一種方法：也就是用parser combinator來產(chǎn)生文法樹，然后我提供一個(gè)函數(shù)來把它轉(zhuǎn)換成一份對(duì)應(yīng)的C#遞歸下降語法分析器的代碼（跟yacc很像哈，雖然他用的是LALR），最后編譯它。因此只需要在IDE第一次打開某個(gè)語言的代碼文件的時(shí)候編譯出這個(gè)語法分析器，在IDE關(guān)掉之前就都可以用了。

    那語法分析器要產(chǎn)生什么語法樹呢？這個(gè)還是要我們自己來解決的。不過我采取了一種比較偷懶的方法。我先寫了一個(gè)語法樹的基類（vlpp.codeplex.com后Candidate\CodeBoxControl\CodeBoxControl\CodeProvider\*.cs），然后只要你給我一個(gè)這樣子的虛類：

    那么你就可以用CodeNode.Create<AddNode>()或者CodeNode.Create<NumberNode>()來獲得相應(yīng)的實(shí)現(xiàn)了。至于CodeNode的聲明是這樣的：

    因此當(dāng)你往AddNode.Left賦值的時(shí)候，也就是等于在寫CodeNode.Nodes["Left"]，這就是Create<T>所提供的實(shí)現(xiàn)了。當(dāng)然寫進(jìn)去了之后ParentNode和Scope屬性就會(huì)立刻有效了。這種方法還是可以剩下你不少時(shí)間的。

    今天就說到這里了，然后我就得去開發(fā)那個(gè)C#的parser combinator并且想好一個(gè)單元測(cè)試的對(duì)策（這也是一種練習(xí)哈），然后再繼續(xù)寫博客了。不過中秋節(jié)那一整個(gè)星期都要回家辦點(diǎn)事情所以估計(jì)會(huì)暫停。     今天先放圖哈。智能完成已經(jīng)開始做試驗(yàn)了不過距離能看還差很遠(yuǎn)，所以今天先繼續(xù)談一下著色的事情。

    這就是我暫時(shí)實(shí)現(xiàn)的所有功能了。首先著色算法可以外掛，其次左邊那個(gè)邊欄（大小和繪制均可以訂制）操作他的時(shí)候會(huì)發(fā)生什么事情也是外掛的。著色器與“斷點(diǎn)變紅”是分離在兩個(gè)不同的插件接口里面的，原因上一篇文章說過了。你們可能還會(huì)注意到那個(gè)灰色的框框。那個(gè)框框的確是會(huì)被編輯器當(dāng)成一個(gè)整體來對(duì)待，不過我絕對(duì)還沒有實(shí)現(xiàn)折疊。因?yàn)樵谖业脑O(shè)計(jì)里面，如何進(jìn)行折疊應(yīng)該是插件的事情，控件本身只要處理好怎么編輯和顯示就行了。還有一個(gè)比較難發(fā)現(xiàn)的就是，我這玩意兒也是支持輸入法的，輸入法的窗口會(huì)跟隨光標(biāo)移動(dòng)……

    在開發(fā)這個(gè)東西的時(shí)候我嘗試了兩種新方法。第一種是MVC。MVC開發(fā)高亮還真是容易啊，不僅文字緩存部分（C#也是可以精確控制內(nèi)存的哈）可以獨(dú)立出來，連編輯操作（各種按鍵鼠標(biāo)組合）其實(shí)也可以不做在控件里面。這樣有什么好處呢，當(dāng)然是可以進(jìn)行高強(qiáng)度的單元測(cè)試了哈。第二種就是GUI自動(dòng)化，光對(duì)類進(jìn)行單元測(cè)試還是不夠的，Visual Studio 2010為.net單元測(cè)試工程提供了一個(gè)Coded UI Test框架可以給我啟動(dòng)一個(gè)獨(dú)立的外部程序（MFC寫的也行，WinForm寫的也行，WPF寫的也行，網(wǎng)頁都行）然后操作上面的各種控件最后拿到控件里面的信息。不過可惜的是我的文本框并沒有按照Windows的UI Automation標(biāo)準(zhǔn)來實(shí)現(xiàn)（從而讓盲人也能使用這個(gè)控件），因此只能進(jìn)行鍵盤和鼠標(biāo)的操作，至于我繪制的東西是什么則需要其他方法。C#跨進(jìn)程怎么做最方便呢？當(dāng)然是Windows Communication Foundation了哈。為了寫足夠的單元測(cè)試是要不惜一切D。不過顯然WCF的服務(wù)不可能做在控件里，因此我的solution下面暫時(shí)就有控件工程、測(cè)試工程和被測(cè)試的“獨(dú)立程序”工程了。

    有了GUI自動(dòng)化測(cè)試，我在進(jìn)行重構(gòu)的時(shí)候，就可以放心的修改代碼，然后執(zhí)行測(cè)試程序，去外面喝杯茶。過個(gè)幾分鐘測(cè)試工程就會(huì)跟我報(bào)告一共掛掉了多少個(gè)case，只要修好就行了。這種方法杜絕了絕大多數(shù)由粗心引起的bug。如果你在公司使用類似技術(shù)來對(duì)付你的代碼的話可以有效減少工作時(shí)間，從而讓公司可以榨取更多價(jià)值。

    操作的組合還是比較麻煩的。為了全套支持，我特地操作了一下Visual Studio 2010的文本框，然后對(duì)一些我看不順眼的行為經(jīng)過修改之后，現(xiàn)在已經(jīng)可以實(shí)現(xiàn){LEFT, RIGHT, UP, DOWN, HOME, END, PAGEUP, PAGEDOWN, ENTER, BACKSPACE, DELETE}×{null, CONTROL, SHIFT, CONTROL+SHIFT}共44種操作方法。加上鼠標(biāo)，突破半百。這么復(fù)雜的東西，如果沒有足夠的單元測(cè)試，也沒有足夠的GUI自動(dòng)化測(cè)試的話，隨便改個(gè)什么都很有可能發(fā)生問題的。所以開發(fā)這類程序的時(shí)候要十分小心，一定要寫單元測(cè)試。

    至于著色應(yīng)該怎么測(cè)試呢？只要有了WCF，就十分簡(jiǎn)單了。測(cè)試程序發(fā)送兩個(gè)坐標(biāo)，WCF服務(wù)返回坐標(biāo)之間所有字符的顏色代號(hào)就行了。代號(hào)是可以在測(cè)試程序跟被測(cè)程序之間約定的，所以這種方法就讓測(cè)試變得十分簡(jiǎn)單了。

    開發(fā)這一部分一共花掉我大約四天時(shí)間（假設(shè)不用上班每天能寫8個(gè)小時(shí)，累計(jì)出來的）。當(dāng)然平時(shí)要上班所以實(shí)際花費(fèi)是要多一倍不止的。其實(shí)當(dāng)我在紙上畫出了上圖C#著色器的狀態(tài)機(jī)之后，也沒想到實(shí)現(xiàn)出來速度這么猛的。雖然著色器使用狀態(tài)機(jī)來實(shí)現(xiàn)已經(jīng)是速度最快的方法了（經(jīng)過大學(xué)4年寫編譯器的經(jīng)驗(yàn)……不過我后來用C++做出了一個(gè)能根據(jù)正則表達(dá)式在內(nèi)存中產(chǎn)生詞法分析器的，比手寫的更快），不過還是要感嘆一下.net到了4.0還是比起當(dāng)年的2.0要進(jìn)步無窮多倍的哈。虛擬機(jī)可以在執(zhí)行的時(shí)候才開始產(chǎn)生并優(yōu)化x86代碼，可以讓程序越跑越快（非騙人，編譯原理小白請(qǐng)自行學(xué)習(xí)），這還是靜態(tài)編譯其所不能達(dá)到的。之前還看過channel9上面的視頻講微軟某個(gè)研究院在做一個(gè)全新的javascript引擎（看起來好像沒有加進(jìn)IE9beta），就是用了動(dòng)態(tài)的兩階段profile+optimize+codegen的方法，通過為瓶頸代碼使用激進(jìn)優(yōu)化方法，從而讓總體的運(yùn)行和編譯時(shí)間的總和降到最低。生成X86什么的還是非常麻煩的，總之我已經(jīng)被機(jī)器碼囧了半年，暫時(shí)不想碰JIT了……當(dāng)然這是遲早要再碰一次的。

    寫到這里就先碎覺了，下一篇開始說之前在糾結(jié)的過程中產(chǎn)生的幾個(gè)智能完成的方案。遲早都要把它給做出來的。     在寫這篇文章的時(shí)候，我正在嘗試自己開發(fā)一個(gè)我自己認(rèn)為能拿出去見人的IDE。當(dāng)然此時(shí)此刻我只開展了一點(diǎn)點(diǎn)工作。所以這篇文章沒有什么最終的指導(dǎo)性，而是在記錄我開發(fā)IDE的思考過程。當(dāng)然我覺得之前寫了那么多東西除了開了源之后介紹了我的作品讓大家可以更好的理解并學(xué)習(xí)以外，其實(shí)也沒有什么大的效果（除了幾篇置頂?shù)慕坛涛覀€(gè)人覺得還是有點(diǎn)效果的……）。因此我嘗試做一下改變，把我的思考過程描述出來。一方面我自己可以從一個(gè)更高的高度來審視我自己，第二個(gè)就是如果你們想從我這里拿走什么，或者想教我什么，請(qǐng)自便哈。

    其實(shí)以前并不是沒有開發(fā)過IDE，只是那個(gè)IDE除了語法高亮以外什么都沒有，因此其實(shí)并沒有什么大的用處。個(gè)人認(rèn)為IDE要提供給你的功能有三點(diǎn)：智能提示、集成調(diào)試、輔助部署。當(dāng)然在我眼中最厲害的IDE當(dāng)屬VisualStudio了，各種功能真是非常人性化，而且也跟我的觀點(diǎn)比較一致：我只是想開發(fā)個(gè)編譯器然后開發(fā)個(gè)makefile系統(tǒng)讓別人可以方便一點(diǎn)用我的編譯器而已，為什么我一定要用makefile來組織我的編譯器源代碼啊，一點(diǎn)都不方便（噗

    是個(gè)程序員都是這么想的哈。

    IDE還是好東西。前幾天我在vlpp.codeplex.com上面checkin了一份我開發(fā)的語法高亮編輯器的雛形（下載后打開Candidate\CodeBoxControl\CodeBoxControl.sln），完全用C#寫。我的Demo也是用的C#，外掛了一個(gè)可以分析C#的關(guān)鍵字、字符串和注釋的代碼著色器，在我的機(jī)器上（雖然我覺得比較強(qiáng)大，不過我的程序也是單核的，因此其實(shí)也只有2.7G的頻率）著色一個(gè)將近10萬行的程序只需要半秒鐘。其實(shí)大家大可不必覺得C#很慢，其實(shí)是很快的，慢的是你的內(nèi)心。

    當(dāng)然我也做了一點(diǎn)優(yōu)化，全文著色要半秒，不過其實(shí)你在編輯的時(shí)候是不需要總是全文著色的。所以我的著色器接口做了一點(diǎn)小限制：
    1、你必須用狀態(tài)及實(shí)現(xiàn)，而且狀態(tài)及的狀態(tài)只能用int類型來表達(dá)。
    2、著色必須是上下文無關(guān)的。

    對(duì)于2可能比較難理解。首先C#那個(gè)可以檢查出一個(gè)ID是不是一個(gè)類型然后變色其實(shí)根本不是著色器的任務(wù)（根據(jù)我的設(shè)計(jì)，你可以在另一個(gè)地方臨時(shí)更改顏色，也能實(shí)現(xiàn)）。其次對(duì)于一個(gè)給定的任意字符串前綴，其著色效果不能跟前綴之后的任何字符有關(guān)系。

    因此我只需要記下每一行的末尾著色器當(dāng)時(shí)的狀態(tài)，就可以從任意位置開始到任意位置結(jié)束進(jìn)行部分著色了。因此這里就有很多的優(yōu)化空間。有了這些優(yōu)化之后，我用我的Demo編輯一個(gè)將近10萬行的C#文件的時(shí)候，那個(gè)運(yùn)行在UI線程里面的著色算法絲毫沒有讓我覺得有延遲，只有在少數(shù)情況下（瞬間貼了好幾萬行代碼，然后按ctrl+end跳到全文最后，我不得不對(duì)你貼進(jìn)去的東西立刻著色）才會(huì)讓你感覺到有小于半秒鐘的延遲。所以我覺得這個(gè)設(shè)計(jì)已經(jīng)可以達(dá)到我的要求了，因?yàn)槲易约簩懙拇a一般單個(gè)文件都沒有超過1萬行，所以偶爾給我一個(gè)小于0.05秒的延遲其實(shí)也是無所謂的……

    為什么可以進(jìn)行優(yōu)化呢。你可以想一下，如果我正在對(duì)某一行進(jìn)行編輯，而且這一行后面的代碼都已經(jīng)被著色過了，那么如果你的改動(dòng)都沒有讓行末尾的著色器狀態(tài)發(fā)生變化，那么這一行后面的所有字符都不需要更改他的著色，因此我就可以只對(duì)你當(dāng)前編輯的一行進(jìn)行著色（唯一修改的其實(shí)也就只有那種多行注釋，你一般也不會(huì)寫很多這種多行注釋的，都用的單行……）。一百來個(gè)字符的著色基本上可以忽略，因此無論你的文件有多大，其實(shí)著色速度是跟你平均每行的長(zhǎng)度有關(guān)系，只有在極少數(shù)情況下才會(huì)跟你的行數(shù)有關(guān)系。這個(gè)時(shí)候你可以看到著色器兩個(gè)限制的強(qiáng)大威力了吧。

    那么，當(dāng)我們對(duì)一行代碼進(jìn)行斷點(diǎn)的時(shí)候，代碼顏色的修改是如何做的呢？為了這個(gè)東西去影響著色器那個(gè)強(qiáng)到可以忽略的效率實(shí)屬殺雞取卵，所以答案就是：外掛一個(gè)控制面板接口，讓你可以在顯示某一行的時(shí)候臨時(shí)修改那一行每個(gè)字符顏色。聽起來好像很影響效率，不過我們要相信，一行代碼也就只有那么幾十到一百來個(gè)字符，一屏幕的代碼最多也就一兩千個(gè)字符。任何語言無論多慢，對(duì)一個(gè)一兩千那么長(zhǎng)的數(shù)組賦值，也是奇快無比的，何況是C#這么快的語言……

    因此我們剩下的問題就是如何實(shí)現(xiàn)一個(gè)可以修改文字顏色的普通文本框了哈。經(jīng)過我的3此研究，結(jié)論就是，不要用RichTextBox，你自己自繪從頭寫一個(gè)。第二個(gè)結(jié)論，凡是GUI最好都別用C++，無論GUI類庫(kù)多么好，一個(gè)沒有內(nèi)存管理器就足以讓你覺得很麻煩了，當(dāng)然對(duì)于編譯器本身我還是推薦C++的，因?yàn)榫幾g器雖然算法復(fù)雜，不過結(jié)構(gòu)簡(jiǎn)單，所有的內(nèi)存分配都是可以預(yù)測(cè)的，因此delete起來非常有信心。

    最近一兩個(gè)星期都在糾結(jié)如何實(shí)現(xiàn)一個(gè)簡(jiǎn)單的上下文有關(guān)的智能提示功能（至少按個(gè)"."會(huì)有個(gè)列表什么的）。這個(gè)明天再寫了，今天只有一點(diǎn)點(diǎn)頭緒，還沒完全成型。