win下使用emacs不會是個好選擇，但是也看個人喜好。
在xp和win7下使用過emacs，win8如此高大上的系統，沒用過。想來emacs在win8下也不會有太大問題。下載區gun的主頁就行了，這裏有emacs for windows的gun下載主頁：
plete
分別說說：
ecb，emacs code browser，用於瀏覽代碼，大致看起來是這個樣子：
cedet，eamcs能開發C，就靠它了，全稱是?Connected Graph Editor 主要包含 ede，semantic， eieio，speedbar等組件，提供包括語法分析，跳轉，補全等壹系列基本功能。可以說，沒這個，emacs就是個文本編輯器，有了這個才有了IDE的部分特性。cedet是emacs24自帶的，如果在linux下用，基本不用配置，windows下就要折騰了，具體看這個：/c-cedet.htm ，先看第二篇，再看第壹篇。
tabbar，tabbar-ruler 這個是讓emacs支持tab標簽顯示功能，類似VS的那種文檔展示形式，可選，但是我想用windows下的人都習慣這個
yasnippet和auto-complete 基於縮略詞的模板替換系統和自動補全的前端引擎。這兩個插件配合很好，開發必備，看起來就是這樣：
具體安裝壹言難盡，請多百度谷歌。這個時候百度不壹定好使，google相對可靠的多。這個是emacs插件的配置，還缺mgwin，這個要額外配置，添加exec-path。具體請百度，我沒配過，我emacs都是org寫文檔用的，偶爾騷包用eamcs寫，回頭VS編譯。
如果上面的妳都折騰過了，妳應該會發現新的問題：老子折騰了這麽久，為什麽感覺還沒個VC6+VAX來的實在？問題出在cedet的組件semantic上。它負責進行語法分析，生成tags，顯示函數，進行跳轉和補全。但是這個東西是基於靜態分析的且是純elisp實現的，效率上可想而知。VS的補全是動態進行的且它本身可以利用編譯器的分析結果，所以速度快，補全能力很強。semantic則相反，它不能利用編譯器生成的語法分析樹，自己掃描靜態文件，這個效率可想而知。解決方法麽，在linux下有個GCC的修改版本，可以將分析結果借用給semantic，貌似要額外進行壹些配置，這樣配置過後，semantic就會快很多，起碼不會出現打開個C文件，分析半分鐘這麽誇張。同樣的問題出在auto-complete和yasnippet上。它們同樣沒有編譯器分析結果做支持，所以補全基本是基於縮略詞的，相當的不智能。這些是emacs作為C開發環境的缺點。
這些問題的出現，並不是emacs本身不夠強，實在是沒有大廠商的支持，靠壹群愛好者進行義務開發和維護，很大程度上限制了eamcs作為IDE上的能力。本身這個也不是大問題，emacs被愛好者稱為操作系統，IDE只是人們對它的壹個期望罷了，這本來也不是它的強項，通用和擴展性才是它的靈魂。用emacs和VS比C開發效率，這本來就不公平，有本事妳也去linux命令行跑跑看嘛。
lz加油吧，每個喜愛emacs並為之付出的人，都會得到回報。不要太過計較壹時的得失，emacs絕對是值得信賴的工具，值得妳為他付出。這個道理其實很簡單：除了emacs，妳再也找不出壹個程序，能夠完全按照妳的意願工作。
emacs的神奇來源於它驚天地泣鬼神的設計理念：編寫lisp解釋器，解釋elisp語言，來制作壹個編輯器，這本來就是天才的構想。在emacs的世界裏，絕大多數的功能都是lisp函數的求值帶來的。任何的按鍵，都會觸發解釋器對elisp函數或C函數的求值，運行，然後產生響應的行為。這點可以在eamcs中使用C-h k 來驗證，這個快捷鍵綁定到了describe-key，可以描述妳的按鍵所觸發的函數，它的功能和所在的文件，妳可以很方便地進入這個文件內部觀察elisp實現。emacs根本就是個解釋器+腳本語言的黃金搭檔。通過elisp編程，妳能控制emacs的任何行為，自己編寫elisp函數實現壹些自動化操作，比如通過壹個按鍵自動格式化當前buffer中的所有代碼，編寫正則匹配函數並綁定到響應快捷鍵，這樣可以通過按下妳綁定的按鍵序列，讓emacs自動隱藏指定的行，比如註釋，自動替換選中區域的指定字符序列等等。
總之，emacs無所不能，這個源於它奇思妙想的偉大設計。
以上。