@Kevin Lynx
這么好的名字應(yīng)該早沒了吧，不過好像.Net的域名還留著...

@Rayz
目前是支持腳本的，支持vbs和js。我目前只寫了腳本控制編輯器本身的，只有很簡單的幾個(gè)接口。腳本很重要，我認(rèn)同你的觀點(diǎn)。

@lulu00147
多謝支持，奮戰(zhàn)中。。。

@HUIANG
努力中。。。

GUI操作系統(tǒng)費(fèi)了牛勁才走到今天的地步......額。。。又要復(fù)古？
Vimperator真能提高效率？呵呵。。。。

@lulu00147
努力中。。。

@lulu00147
壓力很大啊。

這內(nèi)存占的。。。。。雖然你解決了，似乎實(shí)用性不是太大。

@lulu00147
Latex是必須支持的。

感謝你的支持，呵呵，目前正在往上安spellchecker.

:-)這次是想把這個(gè)編輯器做成一個(gè)產(chǎn)品。爭取元旦前給你發(fā)一個(gè)版本。

@陳梓瀚(vczh)
期待你發(fā)布一個(gè)可運(yùn)行版本，比拼一下！嘿嘿

你做的有點(diǎn)復(fù)雜了。
類型<->函數(shù)應(yīng)該可解決絕大多數(shù)的應(yīng)用。我是放在Sqlite里面，執(zhí)行select。可以全文掃描SDK形成符號(hào)庫，我用ctags做的。輸出變量的時(shí)候，只要知道類型就可以了（這個(gè)寫的很爛）。不過，我沒對(duì)部分代碼進(jìn)行分析，保存的時(shí)候刷新當(dāng)前頁面的信息而已。sqlite按照字母順序進(jìn)行拆表，當(dāng)前頁面放入內(nèi)存，具有最高優(yōu)先級(jí)，編輯器抽象出一個(gè)List，在加一個(gè)鎖，可以做的很像很像Visual Assist X.
這個(gè)東西不能和編輯器糾纏不清，不然會(huì)很丑陋很丑陋。。。。

如果我沒記錯(cuò)的話，那個(gè)數(shù)字不是卡馬克發(fā)現(xiàn)的，只是被卡馬克用，而出名的。
在很久以前讀quake代碼的時(shí)候，what the fuck讓我忍俊不禁。這個(gè)函數(shù)只是近似，有一些誤差，但是因?yàn)槭怯螒蛏嫌玫模?jì)算兩點(diǎn)間的距離的時(shí)候，那點(diǎn)誤差可以忽略，屏幕本來就是像素的嘛。sqrt的精度要比那個(gè)高，你可以測測。

@Huiang
Dear,等一下版本，很快會(huì)釋出。

>先說一下特色吧, 就是智能換行, 全文掃描標(biāo)點(diǎn)符(分前標(biāo)點(diǎn)后標(biāo)點(diǎn)),
單詞邊界換行唄?

為什么要編程？目的驅(qū)動(dòng)一切。其它都是扯淡。

弄個(gè)HTML里面嵌入各種語言的的試試，呵呵

折疊不應(yīng)該由plugin來處理，否則會(huì)很痛苦的。編輯器本身應(yīng)該提供那些行不顯示的功能，并對(duì)scrollbar和caret的更新提供支持，然后才讓plugin去處理折疊。輸入法光標(biāo)跟隨，那是輸入法本身提供的功能，有的輸入法沒有光標(biāo)跟隨，比如微軟的日語輸入法,而且如果用sogou的輸入法的話，它有一個(gè)bug,在多語言切換之后，就無法跟隨了。正確的處理方法還是自己處理IME消息，然后移動(dòng)窗口。如果不處理的話，那么你輸入一個(gè)句子的話，會(huì)對(duì)每一個(gè)漢字產(chǎn)生一個(gè)OnChar,效率較低。

不用開發(fā)了，直接用我的吧，呵呵

#define GETBIT(NUM, IDX) ((NUM>>(IDX))&1)

#define SETBIT(NUM, IDX) NUM |= (1<<(IDX))

@ooseven
我測試過1500百萬行的文件，沒出現(xiàn)什么問題。你那邊exe目錄下有無生成.RPT文件，有的話，發(fā)給我分析一下。

@溪流
不是，自己寫的。

@mcs51a
WIN2K沒測試過，這應(yīng)該是WTL的問題。回頭看看！

多謝關(guān)注。因工作繁忙，打算在最近釋放出一個(gè)內(nèi)核裸奔版。

@李蒙
scintilla的詞法分析部分都是在以LexXXX打頭的文件中定義的。你在LexCpp中修改應(yīng)該是正確的，之所以沒被反映。我想可能跟你的DLL有關(guān)。
確保你的程序調(diào)用的是你編譯過后的DLL。你可以刪除掉所有的Lex只保留你的Lex試試。

可是看看luatinker

這個(gè)HashClass應(yīng)用太局限了。

不知道該引擎最大的特點(diǎn)是什么？

MegaxEdit的核心已經(jīng)基本開發(fā)完畢了，剩下的只是修修補(bǔ)補(bǔ)。我現(xiàn)在在整合編輯器。包括MDI, 偽SDI, 菜單，工具條，配置，Docking,插件架構(gòu)等。這是個(gè)辛苦活，不過仍在有條不紊的進(jìn)行著。因?yàn)槲抑荒茉谕饲谛菹r(shí)間來做這個(gè)東西的，所以進(jìn)展稍慢。

你這個(gè)內(nèi)存池本身的數(shù)據(jù)結(jié)構(gòu)就不夠優(yōu)化。一些數(shù)據(jù)本身就是可以放在內(nèi)存池中的Data塊的。另外也不知道你為什么選擇5120，我記得windows的也內(nèi)存是4KB.還有你的查找居然是用Map....而且是對(duì)指針進(jìn)行Hash.
Loki當(dāng)中有一個(gè)讓人嘆為觀止的內(nèi)存池實(shí)現(xiàn)，建議你看看，極其小巧與精致。

WTL還是很爽的

無法捕獲over buffer的.

呵呵，好像還在轉(zhuǎn)圈圈哦，O(∩_∩)O~

@HuaHope
呵呵，過年剛回來，沒想到兄臺(tái)就寫了這么多啊，哈哈。給個(gè)聯(lián)系方式，有機(jī)會(huì)好好聊聊

@AptEdit
很榮幸能得到您的評(píng)論.

前陣子過年了，沒來得及回，不好意思。

試用了您的AptEdit，確實(shí)很不錯(cuò)。本人也浸淫編輯器數(shù)年，因此就不在拍馬屁了，呵呵。

AptEdit在基礎(chǔ)架構(gòu)上似乎有點(diǎn)性能問題，尤其是光標(biāo)的定位。在打開《鬼吹燈》這篇小說時(shí)候在文章頭部
進(jìn)行插入刪除操作的時(shí)候會(huì)感到明顯延遲。在進(jìn)行較長的行自動(dòng)換行的時(shí)候也可以明顯地感到延遲。我想可能
是你光標(biāo)定位算法或者判斷重繪區(qū)域較為緩慢所致。我猜測你可能用了行鏈表結(jié)構(gòu)。因此也導(dǎo)致了打開較大帶文法的文件
的時(shí)候進(jìn)行光標(biāo)滾動(dòng)會(huì)感到明顯滯頓。呵呵，瞎猜的

另外，保存行狀態(tài)(正常,編輯過,保存過)你可以用bitset,這樣你就可以不用讓修改該過的行即使撤銷也依然顯示紅色了,還節(jié)省內(nèi)存。

你的詞法分析做的挺不錯(cuò)的,我為了圖省事,當(dāng)遇到影響下一行的狀態(tài)的時(shí)候會(huì)一直往下分析直到該行狀態(tài)不變?yōu)橹埂?br>
在外觀上AptEdit應(yīng)該盡量simple, 我不太喜歡重繪過的Menu. 現(xiàn)在流行的秀丸,Editplus, EmEditor, sakura啊,都極其簡潔。

所以我現(xiàn)在也在考慮做成單進(jìn)程多線程的,看起來是SDI,但是只有一個(gè)實(shí)例，就像WORD那樣。我對(duì)編輯器外圍的這些東西不太感興趣,所以這么多年了
一直研究編輯器本身,不過坦白的說做外圍的這些條條框框還是非常麻煩的。

很高興看到AptEdit開賣了,不知道賣的如何啊,可以的話，我也打算拿出來賣,MegaxEdit的平均性能還是剛剛的~(笑）

Best regards.

三叉樹還真沒研究過，不知道對(duì)Unicode處理咋樣， Trie樹肯定是不行了

@missdeer
坦白的說做成完全TextMate那樣的話，還是有一定的難度的，首先你得自己寫個(gè)解析器，去解釋用戶定義的自動(dòng)完成腳本。我為了省事，去掉嵌套變量，單純用正則來做了，效果還不錯(cuò)。最大的技巧是光標(biāo)的跳轉(zhuǎn)。不過它和編輯器結(jié)合太過緊密，所以我沒有寫出來。如果你沒有試過bundle，你可以下個(gè)最新的EmEditor，它也實(shí)現(xiàn)了，而且不錯(cuò)，原理跟我說的差不多，從它的bundle文件可以看出來。

CString設(shè)計(jì)還是很棒的. 單字符替換可以簡單的掃描即可，如果多字符肯定要重新分配內(nèi)存的。

@lex
我對(duì)Lex并不熟悉，不過剛才試了一下這么做似乎不對(duì)。比如下面這段
.|\n { pos +=; REJECT; }
mmm { printf( "%d:%s", pos, yytext ); }
mmm2 { printf( "%d:%s", pos, yytext ); }

語言仍然是中文，可以在設(shè)置里面變更的

@空明流轉(zhuǎn)
Yes，累加每一個(gè)token，確實(shí)可以得到位置，只是方法稍顯笨拙, 而且必須添加個(gè)空轉(zhuǎn)狀態(tài)。我原本打算直接修改flex的代碼，加入一個(gè)yypos之類的函數(shù)或者變量，無奈lex的代碼太過晦澀啊

@陳梓瀚(vczh)
既然能找到匹配串，肯定就有位置，這是毋庸質(zhì)疑的。不過lex和flex對(duì)此的處理匪夷所思，代碼不按套路出牌，沒找出在哪設(shè)置的。

@空明流轉(zhuǎn)
呵呵，沒看懂，KO掉啥子?

@liuliu
這個(gè)不好說，既然可以往yytext里面拷貝內(nèi)容，總得有個(gè)位置開始拷貝吧

@空明流轉(zhuǎn)
就是當(dāng)前匹配到的字符串在原串中的位置。

你這個(gè)一點(diǎn)都不通用, 我Subclass Edit后，接受鍵盤輸入，不存入Edit，自己編碼存儲(chǔ)，Edit內(nèi)則存入亂起八糟的數(shù)據(jù)，或者就直接存*, 我甚至可以不用ES_PASSWORD風(fēng)格,你一點(diǎn)轍都沒有，還不如鍵盤記錄。

有沒有2005的啊

能不能不要這么發(fā)文章？啊？不能合并在一塊嗎？弄的首頁上都是你的。。。好嗎