在寫這篇文章的時候，我正在嘗試自己開發一個我自己認為能拿出去見人的IDE。當然此時此刻我只開展了一點點工作。所以這篇文章沒有什么最終的指導性，而是在記錄我開發IDE的思考過程。當然我覺得之前寫了那么多東西除了開了源之后介紹了我的作品讓大家可以更好的理解并學習以外，其實也沒有什么大的效果（除了幾篇置頂的教程我個人覺得還是有點效果的……）。因此我嘗試做一下改變，把我的思考過程描述出來。一方面我自己可以從一個更高的高度來審視我自己，第二個就是如果你們想從我這里拿走什么，或者想教我什么，請自便哈。

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

    是個程序員都是這么想的哈。

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

    當然我也做了一點優化，全文著色要半秒，不過其實你在編輯的時候是不需要總是全文著色的。所以我的著色器接口做了一點小限制：
    1、你必須用狀態及實現，而且狀態及的狀態只能用int類型來表達。
    2、著色必須是上下文無關的。

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

    因此我只需要記下每一行的末尾著色器當時的狀態，就可以從任意位置開始到任意位置結束進行部分著色了。因此這里就有很多的優化空間。有了這些優化之后，我用我的Demo編輯一個將近10萬行的C#文件的時候，那個運行在UI線程里面的著色算法絲毫沒有讓我覺得有延遲，只有在少數情況下（瞬間貼了好幾萬行代碼，然后按ctrl+end跳到全文最后，我不得不對你貼進去的東西立刻著色）才會讓你感覺到有小于半秒鐘的延遲。所以我覺得這個設計已經可以達到我的要求了，因為我自己寫的代碼一般單個文件都沒有超過1萬行，所以偶爾給我一個小于0.05秒的延遲其實也是無所謂的……

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

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

    因此我們剩下的問題就是如何實現一個可以修改文字顏色的普通文本框了哈。經過我的3此研究，結論就是，不要用RichTextBox，你自己自繪從頭寫一個。第二個結論，凡是GUI最好都別用C++，無論GUI類庫多么好，一個沒有內存管理器就足以讓你覺得很麻煩了，當然對于編譯器本身我還是推薦C++的，因為編譯器雖然算法復雜，不過結構簡單，所有的內存分配都是可以預測的，因此delete起來非常有信心。

    最近一兩個星期都在糾結如何實現一個簡單的上下文有關的智能提示功能（至少按個"."會有個列表什么的）。這個明天再寫了，今天只有一點點頭緒，還沒完全成型。