隔了兩個(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)完全出來了，哇哈哈。