Emacs作為IDE編程環(huán)境的不足

寫了一段時間的程序，感受過各種編程環(huán)境，也數(shù)次學(xué)習(xí)Emacs（或者Vi）并期望這兩者能搞定大部分事情。不過，最后還是發(fā)現(xiàn)術(shù)業(yè)有專攻，作為編程環(huán)境的時候，某些情景這哥倆還真的不怎么適合，姑且稱為不足吧，記錄在這里。

這里馬上想說的是，我不是Emacs和Vi的粉絲，但是很喜歡兩者的某些設(shè)計和功能。努力學(xué)習(xí)過他們，在生產(chǎn)環(huán)境中也經(jīng)常用到，但并不精通。如果有我不知道或者說錯的地方，敬請批評指正。另外，這貼無意于討論IDE還是Notepad寫程序誰更高明的問題。

1、項目的組織方式

Emacs首先是作為編輯器而存在而出名（我想Vi也一樣），在不用插件時，它面向的是單個文件，若考慮split和tab方式，則是面向多個單獨的文件。當(dāng)使用了某些插件以后，它可以“看到”并“管理”目錄樹，部分變成了面向目錄的管理方式。無論是面向文件的還是面向目錄樹的，Emacs都首先致力于對于單個文件內(nèi)部編輯功能的強大。項目所用到文件之間的關(guān)聯(lián)，在編譯之前關(guān)聯(lián)是松散的——Emacs把它們當(dāng)做單獨的一個一個文件，至多是以文件系統(tǒng)的目錄樹結(jié)構(gòu)組織。這有的時候很好，確實符合KISS和工具高內(nèi)聚低耦合的思路：通過文件系統(tǒng)組織項目，通過shell直接實現(xiàn)文件的操作以實現(xiàn)項目的管理。而現(xiàn)代的IDE基本都是面對“項目”這個概念。Emacs這種面向文件的方式，相對就有些不足：：

調(diào)整項目的目錄結(jié)構(gòu)，Emacs靠的是命令，文件一多效率就可想而知；（不過這一點是典型的鼠標(biāo)操作優(yōu)勢項目，有點作弊的嫌疑）
依據(jù)當(dāng)前符號在項目內(nèi)跳轉(zhuǎn)，比如點擊函數(shù)定義，直接跳轉(zhuǎn)到函數(shù)體，Emacs對C還支持，對其他語言就。。。；
查找類的繼承結(jié)構(gòu)時，IDE會在項目中找到相應(yīng)的符號并跳轉(zhuǎn)。Emacs并沒有“項目”這個視野，跳轉(zhuǎn)或者類的繼承結(jié)構(gòu)有可能不完整；
項目文件數(shù)目和種類都較多，并且分布在不同目錄中時。這種情況下IDE一般會把文件按類型分門別類列好，也就是說，導(dǎo)航欄強大的多；
IDE會根據(jù)對項目的操作（添加文件、刪除文件、改名、改目錄）自動變更項目文件或者Build腳本，而Emacs需要在做了這些變更以后，再慢慢到腳本里找到相應(yīng)位置進(jìn)行更行；
想象一個極端場景吧，一個項目擁有100個文件，其中80個代碼文件，放在一個目錄中（敘述簡單起見）。由于重構(gòu)的需要，我們需要調(diào)整目錄結(jié)構(gòu)，根據(jù)命名空間將他們分門別類放進(jìn)相應(yīng)的目錄，這些文件有若干個類，有幾個類方法很多，參數(shù)復(fù)雜，類繼承系統(tǒng)也超過3層。這種場景現(xiàn)代IDE相對能較快速的解決問題，這個時候Emacs搞不好還在來回翻查目錄移動源代碼或者是同步Build腳本。

尤其是現(xiàn)在大家都在寫著“膠水”代碼，更注重“結(jié)構(gòu)”而不會在一個文件中死磕很久（我相信做算法的牛人或許不是這樣），Emacs的優(yōu)勢在弱化，而對于項目管理的劣勢就更明顯。前兩天還看了篇文章說程序員真正在“寫”程序的時間不會超過50%呢。

2、缺失的功能和黑客的插件

Emacs和Vi本身在文字處理方面的功能非常強大（低耦合高內(nèi)聚嘛），由于某些非文字編輯功能的缺失而且系統(tǒng)又比較開放，各種插件層出不窮。可以說，沒這些插件真就沒有Emacs作作為編程環(huán)境的今天（其實裸奔Emacs對編程支持得還算友好啦，Vi裸奔基本什么都沒有么），什么Colortheme，numberline，etags，CEDET，cscope等等等等的插件大大增強了Emacs在程序開發(fā)方面的能力（甚至有部分彌補了上面第一部分我說的不足）。相應(yīng)的，Vi也有許許多多各種各樣的插件（比如上推特啦，收郵件啦，聊Gtalk啦-_-）。但是，但是！這些插件有著相當(dāng)濃厚的黑客味道：

配置插件配置到你崩潰，不斷改配置，重試，改配置，重試，直到你的Emacs再也起不來鳥~~~>_<~~~
除了幾個著名插件，其他插件的完成度真的比較讓人懷疑，興趣愛好么，寫到一半沒興趣了怎么辦？講與時俱進(jìn)講了這么久了，插件還真是做不到與時俱進(jìn)那。
C和C++加上插件基本成套能用，其他語言那？記得有一次，一個html/css/js的項目寫到一半，突發(fā)奇想用了一會兒vim+網(wǎng)上大牛推薦的幾個著名插件，哎呦我的媽，這是回到了侏羅紀(jì)嗎？基本的代碼著色，代碼縮進(jìn)還能做的更差一點嗎？
當(dāng)然，隨著插件的完善，Emacs和Vim還是有更完美的希望的。也許什么時候Netbeans Eclipse這些都被干翻了，IBM和Oracle回到Emacs或者Vi懷抱，又或者Google被弄得沒ide用了，這時候Emacs和Vim插件就有希望了。也就是說，Emacs作為開發(fā)環(huán)境缺乏大廠的支持，這是它的一個硬傷。

3、高級特性

下面這些高級特性上，Emacs和Vim的差距也比較大：

首先要說的高級特性就是智能感知和補全，在微軟叫Intellisense，在其他的廠，好吧，就叫Auto-Complete… 這個差距就大了去了�；旧螮macs在C和C++領(lǐng)域還能撐一下，只能說略輸現(xiàn)代IDE一點，基于項目和語法分析的插件勉強趕上時代（勉強比Eclipse，Netbeans這種差一點，和VC和SlickEdit比那就是廁所里點燈）。其他語言的智能感知和補全基本上就是農(nóng)業(yè)社會了——基本上就是基于單詞表的，囧。其實Emacs也做得出來，不過這種東西沒大廠雇一幫人，做個能用的蠻難。
其次是重構(gòu)啊，單元測試啊，源代碼管理啊這些熱點特性基本也沒戲了，Emacs里只能Shell開起來，小碎步抖起來了。
再然后是調(diào)試的支持。Emacs也好Vi也好，插件一個不落全裝上，對GDB支持還是蠻好的。即使這樣，GDB目前看起來調(diào)試功能和Visual Studio還是有一定差距（舉個例子，VS好幾年前開始支持泛型容器直接看內(nèi)容了，可能我土鱉，不知道GDB也支持了）。然后，其他語言的調(diào)試，又是一片悲劇，插件又沒跟上！
最后再提一小點：對于類庫、框架、插件的管理和支持。Eclipse，Netbeans，VisualStudio都有比較完善的插件管理機制，你要哪些插件，隨你選，然后自動下載安裝搞定。Emacs和Vi滿世界找插件，下載以后改配置文件，沒配置對還要悲劇�，F(xiàn)代IDE對于某些程序需要的類庫框架也是這種管理方式，搜索，下載，直接加入項目文件或者build文件，然后對于框架有較多的自動生成功能（比TextMate的Bundles高檔多了，基于語法分析的一般）。不過說實話，這點寫成Emacs的缺點還真有點心虛，因為這本來就是集市和大教堂的區(qū)別。
總的來說，比較根本的缺點其實只有兩個：面向文件而不是面向工程的管理方式；沒有大廠支持。前者是由于Emacs（Vi）編輯器的本質(zhì)造成的，后者，額，我也不知道是什么造成的。

洋洋灑灑寫了這么多，其實我還是挺喜歡Emacs也挺喜歡Vi的，他倆最吸引我的其實還是全鍵盤的操作方式——相當(dāng)?shù)难bB啊，給別人演示的時候倍兒有面子——還有就是奇快的速度，拿來做一些小項目速度很快也很順手。但是挨踢界確實也是一日千里，Emacs和Vi能迎頭趕上就好。

Emacs本身定位上可能就不是代碼編輯器,至少流行的沒見過哪個在文字窗口顯示圖片的,不過這也有個好處就是會有一些支持latex預(yù)覽的插件

VI/Emacs是頂級高手用來開發(fā)操作系統(tǒng)，數(shù)據(jù)庫，編譯器，新的編程語言等等，你說NB嗎？
當(dāng)然這種東西最好是有高手帶，因為學(xué)習(xí)曲線非常的陡。

VS2010確實很好，要是再穩(wěn)定點就更好了。

Emacs和VI也有他們的好處，也有些文章介紹的。我覺得最牛逼的地方是這兩個東西可以完全脫離鼠標(biāo)。