摘要: 非常感謝HuaHope含金量如此高的評論。拋磚引玉，結果釣了塊鉆石。

Megax點評：

Scintilla： 目前Scintilla有一統江湖的趨勢。只要是新開發的軟件工具能夠用到高級編輯器的地方基本上就會用它了。的確Scintilla為一些開發提供了便利，但是，是不是也阻礙了編輯器發展的進程??？沒人愿意開發了，還會有進步嘛？所以說，有時候開源并不一定是好事，你開源開的不好就罷了，開的好了，就會擠掉很多優秀的共享軟件，以至于沒人來做這項了。

另外Scintilla的出現導致同質化非常嚴重，個個都長的差不多，操作也差不多，體現不出特點，這個HuaHope的雜談中有描述。如果一個編輯器要定位于一個專業文本編輯軟件，比如現在的Editplus, UlrtaEdit那樣，我覺得還是不要采用Scintilla的較好，當然如果像Code：Blocks定位于IDE，采用Scintilla就是更快更好的選擇了。坦白的說，開發高性能多用途編輯器難度是很高的。  閱讀全文      摘要: 很多人可能沒有聽過tab trigger這個功能，那么諸位可以在google一把即可知道其為何物。
本來我是打算把這樣的功能放倒插件里面做的，可是一想到最后能為我的編輯器開發插件的，
在初期估計也沒啥人，于是乎還是在內核上給予支持吧。

本篇文章即是分析如何去實現該功能的，事實上，我已經在MegaxEdit基本上實現了。不過相較于
TextMate功能有所縮水。縮水的原因主要是因為我采用了正則表達式去替換實現的，而絕大多數
正則表達式庫是不支持嵌套的(本人使用了日本的鬼車正則庫)，所以在我的編輯器里面變量里面
不可以在定義變量。

在我的編輯器里面，這個東西不叫TextMate的Bundle，我給起了個名字叫HotText, hoho~~~

首先我們看一下下面的語句：  閱讀全文 還是避免不了解散，哎。
什么也不想說了，哎。
     摘要: 最近閑的蛋疼，遂把編輯器里面的詞法分析整整，發現這真是個累活啊，完全是重復性的勞動，
而且一不小心就出錯，一旦添加狀態的話，也得好好修改。遂萌生自動化之的想法。

花了小半天重拾LEX的語法，用法，狀態標記等等，寫了個小sample，確實不錯，擴展性也強，
幾分鐘就可以構造出一個新的詞法分析出來,而且效率雖說比手寫的慢，不過一般的應用足以
對付了，歡喜之。

正當我打算做個wrapper的時候，這才發現LEX竟然不支持獲取當前匹配的匹配位置，
歐，賣疙瘩，不會吧。于是乎在yyinput里面設置個變量標記一下，也不行，因為LEX會預讀。
額的神啊，不會吧。  閱讀全文      摘要: 代碼折疊這個功能，我最早是在Dreamweaver里面看到的，具體哪個版本記不清了，好多年了。

當時DM的實現是當你選擇文本的時候，在編輯器的左側，有一個折疊的提示，提示你可以把選中的

文本折疊起來。那個時候覺得這個功能，毫無用處。不過自從VisualStudio2003以來，代碼折疊

這個功能幾乎成為了程序員的必備。

的確，在瀏覽代碼的時候，代碼折疊可以帶來一些好處，讓重點凸顯在用戶的面前，或者可以拉近兩塊

相隔很遠的代碼，實現比較。當然，這個也完全可以通過分割視圖完成。

在眾多的編輯器當中，我認為單純就代碼折疊而言，目前實現的最好的還是VisualStudio，它

可以根據語言上下文的關系，即語法，進行代碼折疊，這是其它編輯器無法企及的。當然，它本身也是

一個重量級的IDE，超出了簡單編輯器的范疇。

本文試圖描述代碼折疊最基本的思路，沒有具體的代碼。其實這個功能并不難實現，相反很簡單。

  閱讀全文      摘要: 【因工作原因，好久不更新了，向各位關心的朋友說聲道歉】

去年的某一天，對MegaxEdit進行了整理，因最后MFC靜態編譯出來的東西較大，遂萌生往WTL轉移的想法。

前前后后花了很長事件移植完畢，與其說是移植，倒不如說是重寫。

現在編譯出來只有300K左右，壓縮一下，100多K，挺小巧。

最近反復在想，我為什么做這個東西？最后的答案是：興趣。  閱讀全文      摘要: 今天在csdn上看了一篇文章，叫做《到底是該做windows還是linux程序員？》。很顯然這是一個欲從事IT行業的新人所發的帖子。csdn也經營了這么多年了，按理說高人該不少。但是看看回復，確實讓人覺得很可笑。  閱讀全文

這陣子把代碼內核重新構造一遍，不過外圍的代碼還是耦合度比較高。有機會好好考慮考慮。

添加了一個CmdBar，打算集成一些常用的命令，比如cmd啊，grep啊，sort工具之類的，像vi那樣，敲擊代碼調用一些命令

查找方面，反向查找還沒有做，看來我得自己寫了，比較熟悉kmp算法，就打算用這個了。不過比較奇怪的是c函數庫帶的strstr效率竟然比

kmp和BM算法的都快。

發個截圖作個紀念。

     摘要: 編輯器制作之語法加亮基本原理在上一篇文章里，我簡單的提及了語法加亮的基本思路，下面在總結概括一下。

筆者認為，對于編輯器而言，如果支持非常嚴格的語法加亮的話，那么擴展性是很低的。那么在擴展性和正確性之間，我們應該取得一個平衡。這個平衡就是既要保證編輯器的高效率運轉，又要保持文本配置文件的可編輯性。

首先，幾乎所有的編程語言都具有某種共性，這些共性概括如下：
1.關鍵字
2.注釋
3.字符串
4.Delimiters
5.普通字符

詳細....  閱讀全文