為什麼比起 Emacs,更多人使用 vim?
- 在默認情況下,Emacs 比 vim 更友好,而且更像一個 native app。熟悉 vim 的人也能用 evil-mode 正常使用 Emacs。
- Emacs 擁有 org-mode,vim 沒有完美的模擬器。
- Vim 開啟大文件的性能很成問題。
- Emacs 的配置語言 ELisp 比起 vimscript 要高一大截。Emacs 對 Lisp 更友好,能當 IDE 用。
這個問題不是探討那個編輯器更好,而是討論為什麼 vim 的用戶比 Emacs 的多那麼多。
請不要推薦 VS、Jetbrains 家的 IDE 等,因為各大靜態語言的編譯器大多提供工具,如 Go Tools、clang-tools 等。
簡單的說,vim比emacs更簡單且更輕便,也可以滿足大多數人的編輯需求。但還是有不少問題要解釋下
- 用emacs都是上輩子折了小拇指的天使?
編輯方式(vi-mode)的不是真正的原因,evil絲毫不弱於vim,且vim的編輯類插件在emacs中幾乎都能找到等價的替代品。而且spacemacs的流行證明了emacs黨中也有相當數量的人傾心於vi-mode。
除此之外,藉助於emacs強大的可拓展性,有很多人在研究比vi-mode更加高效的按鍵方案,這些方案很難流行,就像即使Dvorak比Qwerty鍵盤高效,也很難流行一樣。- 伸手黨適合用emacs?
@Jacky Liu 的答案說道其中一個原因是因為vim可以使用外部語言而不像emacs傾向於完全使用elisp解決(實際上可以用外部語言),這確實是vim更加流行的原因。但是
如果你是伸手黨,想用別人寫好的插件,那 Emacs 的插件種類多。如果你想自己寫插件,那 Vim + Python 更強大。
這種說法讓我很尷尬,這算是誇emacs的生態更好呢,還是暗示(好暗)伸手黨才適合用emacs呢。
可以肯定的一點是,伸手黨絕不適合用emacs,也同樣不適合用vim。- 用python寫插件比elisp更高明?
其實用elisp寫插件沒有想像中的那麼困難,使用python寫vim插件也沒有想像中的那麼隨心所欲(最後還是要面對蹩腳的vimscript)。
我給vim和emacs都寫過插件,elisp給我的感覺和整個emacs渾然一體,因為emacs本身就是由大量的lisp和少量c構成的,你甚至可以直接在emacs里看到各種方法的實現細節。而vim插件之間的溝通相比之下只能靠開issue去要求另外一個插件的作者給介面(尤其當那個插件是python寫的時候,它在外界看來基本是個黑箱)。當然並不是每個人都喜歡elisp,elisp最大的劣勢是缺少流行語言那樣海量的庫。這也是為什麼vim更流行,因為會其他語言的人更多。- Vim打開大文件性能很差?
這點我必須要黑一下emacs,emacs打開大文件性能也很差。
經人糾正相比之下確實是vim打開大文件的性能更慘,atom也直接不允許打開2m以上的文件,看來是通病吧。
- 到底那個更好?
Follow your heart.這不是什麼聖戰,你喜歡什麼用什麼就好,我見過很多emacs黨都是同時也很熟悉vim的。
秀一發我最近完成的 emacs 插件,其實有個gif但知乎不給放動圖可以在下面的地址看到。
CodeFalling/blog-admin: Write blog in emacs...
emacs現在甚至有 emacs version manager(嗯就像nvm一樣是管理emacs的版本的),以及各種現代化的elisp測試框架構建工具等,不是有些人想像中的上個時代的東西,emacs一直在進步。看到這裡仍然對emacs有興趣的可以加入emacs-cn slack社區(需要梯子):Join emacs-cn on Slack!利益相關:前vim黨,現spacemacs 黨最後, Happy hacking!
仔細搜了搜,發現確實沒有討論過相關的問題。然則你的問題仍然是主觀的。你並不是真的想問 vim 為什麼用戶多,而是想問,為什麼你覺得 emacs 更好,但用戶數量沒更多。如果要回答你的問題,那麼很簡單:你提到的一部分好處並不算是好處,另外一部分好處對大部分人來說意義不大。那麼來分析一下你說的幾點:
在默認情況下,Emacs 比 vim 更友好,而且更像一個 native app。熟悉 vim 的人也能用 evil-mode 正常使用 Emacs。
事實上,更像 native app 的這個特點,對目標用戶而言毫無優勢,文本編輯器的界面並不重要。——vim只需要掌握簡單的幾個命令,相比其他非專業的文本編輯工具就能大幅度提升文本編輯效率。這種簡單粗暴的低門檻可能也造成了vim更普及。emacs用好了確實是神器,然而更多的人在發現它的優點之前就已經放棄了。
Emacs 擁有 org-mode,vim 沒有完美的模擬器。
然而這只是個小眾需求,這個優勢對大部分用戶而言並沒有意義。
Vim 開啟大文件的性能很成問題。
不知道你指的是什麼,vim 打開 8G 的文本文件也是秒開,你確定你使用的是正常版本的 vim?
Emacs 的配置語言 ELisp 比起 vimscript 要高一大截。Emacs 對 Lisp 更友好,能當 IDE 用。
然而這也只是個小眾需求,大多數用戶並不需要親自寫腳本開發配置。而且lisp對於懂lisp的用戶來說是神器,對不懂lisp的用戶來說,簡直就是洪水猛獸。
最後:vim是一個優秀的文本編輯器,emacs是一個帶有文本編輯功能的操作系統。emacs毫無疑問具有比vim更強大的功能,但也許,更多的人覺得一個文本編輯器能完成的工作並不需要動用一個操作系統?
我是一個非程序員的 VIM 用戶,我會用 VIM 來寫一點簡單的代碼,但是多數情況下,VIM 對我來說是一個「文本編輯器」,而不是「代碼編輯器」,而我需要的正是一個文本編輯器。
題主列舉了一些 Emacs 和 VIM 的不同,可能在程序員眼中,這是 Emacs 相對於 VIM 的優勢,但是在我看來,則並不是這樣。
1. 在默認情況下,Emacs 比 vim 更友好。這是事實,但 elisp 並不比 vim language 友好。Emacs 上手就能好好的打字,而用 VIM 起碼得知道 Normal 和 Insert 兩個模式,否則字都打不了。但是,notepad 難道不是更加友好嗎?我放棄了 notepad、notepad++ 、em editor 等等這些文本編輯器(當時 Sublime Text 還沒有出名),來接觸 Emacs 或者 VIM ,並不是因為之前那些編輯器都不夠友好,而是他們不夠高效——十分不夠,所以才會硬起頭皮來摸這兩個讓人困惑的「編程利器」。
但是,隨著了解的深入,我發現 Emacs 比 VIM 更不友好,更準確的說法是 elisp 比 vim language 更不友好。可能 el 作為編程語言比 viml 優秀很多,可能 viml 作為編程語言來說很爛,但是對於一個不大懂編程的用戶而言,viml 比 el 好懂太多了。
2. Emacs 擁有 org-mode 。這是事實,org-mode 確實是純文本編輯的利器,這也是讓我多次想要放棄 VIM 轉到 Emacs 的原因。但是無奈 Emacs 門檻太高。另一方面,我對 org-mode 的需求實際上只有兩個:outline 和 帶計算功能的 todo list ,這兩個功能在 VIM 中有 VimOutliner 這個插件可以用,算是基本滿足了。而且 VIM 還有 Voom 這個插件,可以實現非常棒的樹狀側邊欄,在 org-mode 中反而沒有很方便的實現(之前經過搜索,聽聞是可以用 mini buffer 來實現)。
3. Vim 開啟大文件的性能很成問題。VIM 通常被詬病的實際上並不是處理大文件不行,而是處理長行不行。一個百來 K 的文件,如果只有 1 行的,你用 VIM 來操作也會覺得想死。對於運維人員,幸運的是,在一般的文本處理過程中,不會碰到那麼長的行,這並不是一個痛點。
4. Emacs 的配置語言 ELisp 比起 vimscript 要高一大截。這是在第 1 點就說到的問題。對於一個沒有編程背景的人來說,事情並不是這樣的。vim language 實際上更友好,也更容易看懂。
對於文本編輯而言,實際上並沒有什麼很高級的編程需求。我們接觸得最多的可能就是一些文本的查找替換。 vim language 的優勢在於,它和 VIM 的操作是一致的,這降低了學習和使用的成本。
比如,在 VIM 中進行替換,就是:%s/pattern/new string/g
同樣的命令,直接複製到 vim script 中就能跑。如果你要寫一個函數進行一系列的查找替換,實際上只有把全部的查找替換命令直接塞到 vim script 裡面就可以了。
此外還有 normal 命令可以讓用戶直接編寫鍵盤的操作。你想要什麼操作,直接在腳本裡面寫就好了,這是十分直觀和容易學習的,而 elisp 就難懂得多。我覺得只是vim(以及其前身vi)體積更小,安裝得更廣泛一點吧。emacs很多發行版默認都不裝的。
身為Emacs忠實用戶,對Emacs是又愛又恨。
其實我是從vim入手研究編輯器的,因為vim最直接展現了高效編輯的理念,模式編輯/讀寫分離確實是很完美的一個設定。後來想學Lisp和Python又苦於找不到一個輕量級IDE,才入了Emacs大坑(一直都是搭配evil-mode使用)。到現在,我仍然認為小規模的Python開發使用Emacs搭載IPython是一個極佳選項(重構除外..
但是Emacs也有積重難返的問題。一個問題就在於Emacs Lisp。
ELisp是一門很強大的語言,什麼都可以做,最近為了寫LaTeX我還自己寫了個小東西online-langtool/online-langtool.el at master · Shellay/online-langtool · GitHub,藉助網上的檢查引擎來檢查選定段落的語法錯誤,Elisp內置了url-request和xml-parsing相關的功能,很方便,有興趣的同學可以關注一下。
雖然東西微不足道,但這基本上反映了Emacs的使用概念:有什麼需求,馬上動手寫ELisp,基於ELisp強大而完整的API生態圈,問題一定可以解決。隨著時間的推移,你自己的插件可以不斷完善,最終可能發展成為evil-mode、org-mode、AUCTeX這樣強大的巨型怪物。
Emacs Lisp雖然強大,但設計上卻有很多不適應時代需求的地方。
- 第一要命的是沒有命名空間/沒有模塊,所有的函數都是全局的,結果就是函數命名體系歧義叢生,時刻都要擔心變數和函數取名不要把內置變數複寫了。我讀過許多插件的源碼,插件作者為了保證自己編碼過程中的一致性,基本會把他常用的內置API函數加上自己的前綴alias一遍。
- 第二要命的是Lisp方言自身的問題,比如NIL同時代表空列表和布爾假,t這個特別的單字母代表布爾真,關鍵詞一會是defun一會是defxxx一會是define-xxx-xxx,非常不優雅。據說UNIX系的Guile希望借優雅美麗的Scheme女神把Emacs重構一遍,暫時還沒有後話。沒辦法,ELisp比Common Lisp出現得還早,對語言設計本身不能苛求太多。奇妙的是,ELisp的函數式特性不完整,比如對閉包的支持問題,函數作為變數傳遞問題。在類型系統日益受到重視的今天,舊式的ELisp的動態特性和偽函數式顯得越來越尷尬。
另一方面,許多開發API的人其實是吧ELisp當作命令式語言來用,結果就是Lisp最有函數式特色的括弧更多時候成為了累贅。- 第三要命的就是性能。裝了幾個包之後,package-initialize解釋執行所消耗的時間就已經很可觀了,啟動變得很慢。由於上述語言設計導致的靜態優化的局限,使得類型系統難以應用。所以只好靜靜地看著它慢,或者費點心機搞幾個不同的portable profiles,用於不同的場景。
新晉的編輯器比如Sublime Text,在功能接近Emacs的前提下,速度真的秒Emacs兩條街,而且顏值還高。不過什麼時候Sublime真正完美支持了Emacs中的comint類似功能(即和操作系統直接交互和反饋的通用解釋器模塊,可以說是Emacs真正的killer featuer),可以無疑難地構造一個REPL的環境並支持一切操作系統常用指令,才能在功能上大致趕上Emacs的腳步。
最近有個叫Light Table的編輯器浮出水面,把clojure作為內核語言,有點相當於一個基於clojure lisp的Emacs,界面上採用的也是比較新比較美的技術,支持更高級的widgets(而不像Emacs中什麼widget都是Face......),加上clojure的設計廣受讚譽,所以顯得很promising。但它畢竟圖樣,在生態上追趕Emacs仍然需要比較長的時間。而且目前看來,性能也比較捉急。
--------------------------------
總結一下,從功利的角度,學Vim還是很好很必要的,因為Vim這樣的高效編輯模式越來越多得到各類IDE的支持,對於提高產能有切實幫助。至於Emacs,更適合當作一個小小的操作系統來研究,自己搞一些拓展,加深對工具的認識,不僅有樂趣,也是很有助益的,而且還能破除神秘的嚮往,收穫很多槽點,是不是很值?(霧vim必修,emacs選修
因為 Vim 比 Emacs 強,就這麼簡單。
Emacs 是 70 年代發明的,Vim 是 90 年代發明的,我傾向於認為它們之間有代差。顯然 Emacs 和 Vim 都清楚,要想成為強大的編輯器,必須有強大的擴展語言。它們的差別在於,Vim 的作者明白一件事: 我不需要自己再發明一種語言,和已經成功的語言搞好合作才是對路。所以 Vim 從很早期就提供外部語言介面,我記得最先支持的語言 是 Tcl。後來逐漸把主流腳本語言都囊括了進去,包括 Perl,Python,Ruby。尤其是 Python,作為最流行的通用腳本語言,完勝 Elisp。
相比之下,Vim 自帶的語言直到 7.1 版還都沒有 float 類型,7.2 版才加進去。所以作者的思路很清楚:如果用戶想要寫功能比較複雜的插件,那就應該用外部語言來寫。VimL 只用來配置一下 Vim 就好。
許多人喜歡說 Vim 自帶的語言太弱雞,跟 Elisp 差很遠,這麼說的人對 Vim 的了解不夠。VimL 本來就是作為一種工具配置語言設計的。它看起來比工具配置語言要強這不是它的錯,把它當成通用語言來用才是用戶的錯。要說起來,Elisp 也是種工具擴展語言。一些通用語言必須有的特性,比如多線程,比如組件管理,它都沒有。
這就是時代的差別。在 Emacs 發明的 70 年代,腳本語言還不成熟,沒有現成的可用。Emacs 只好在 Lisp 基礎上先改出一個 Elisp,然後再以 Elisp 為基礎構建了 Emacs 編輯器。這種 「可擴展編輯器」 當時刷新了人們的認知,Elisp 也確實很強大,讓 Emacs 贏得了 「功能最強,擴展性最好」 的名聲。但是畢竟它太早了。後來隨著其它腳本語言的崛起,Elisp 從前的成績逐漸變成它的包袱。比如它想改掉動態名空間,想添加多線程特性,但是卻發現,因為兼容性的關係,沒法改了。
------------------------------------------- 補記 --------------------------------------------
接下來說說 Vim 吧。當你花幾分鐘時間編譯了一個帶 Python 介面的 Vim 以後,你的 Vim 就內嵌了 Python 解釋器,你得到的就是這兩個工具的合體。我就是覺得,Vim 的這個設計思想,比 70 年代的 Emacs 要先進。
我知道,現在有 Pymacs 的存在,Emacs 也可以整合 Python。但是用起來是否方便,特性有沒有受限,我沒用過就不知道了。函數式語言 和 過程式語言 要整合,應該會困難些。而 VimL 腳本只要插入兩行標識符,中間就可以寫 Python 代碼了。因為都是過程式語言,順序執行就好。
有了 Python 介面以後,理論上所有 Python 應用都可能成為你的 Vim 插件。這潛力夠大吧?當然,許多 Python 應用都是自帶 GUI 的獨立程序,沒這個必要。但如果你只想要個文字版,那就真的可以。Vim 黨如果想折騰的話,可以捯飭出一些遠比煮咖啡更歪門斜道的插件出來。
但是現實中,Emacs 的插件種類比 Vim 多,功能也比 Vim 插件強。為什麼?因為 Vim 的好處同時也是它的壞處。想用外部語言插件,就得自己編譯 Vim,這個作者幫不了你,別忘了 Windows 和 Linux 是兩回事。然後呢?Py3 下寫的插件,Py2 的介面能用嗎?甚至 3.4 下面寫的,3.2 能用嗎?Vim 7.4 下寫的,別人是 7.3 能用嗎?重複,別忘了 Windows 和 Linux 。假設用戶的 Python 版本有 7 種,Vim 版本有 5 種,操作系統 2 種,那麼你作為一個負責任的插件作者,需要測試的組合是 。。。就算所有這些你都搞定了,等 Python 或 Vim 一升級新版本,一定還有一堆掛掉的來找你,這些,都不是你作為插件作者能控制的。
------------------------------------------------ 結論 ---------------------------------------------------
所以情況就是這樣,不是 Vim 不能有那些五花八門的插件,而是:第一,需要自己編譯嚇跑了一大半用戶,第二,通用性的限制,寫了實在維護不起,乾脆誰要用,誰就自己寫。
怎麼取捨,就看個人需求。如果你是伸手黨,想用別人寫好的插件,那 Emacs 的插件種類多。如果你想自己寫插件,那 Vim + Python 更強大。畢竟有什麼能比自己寫插件更加彰顯逼格呢?但是像有些人說的,「Emacs 功能比 Vim 強,因為 Elisp 比 VimL 強」,這個說法是錯的,是誤解。
Emacs 比 Vim 還有另一個好處,就是界面特性豐富,可以做的比較花哨。但是 Vim 實現層級低,運行速度快,可以抵消了。
所以回到題主的問題,為什麼用 Vim 的人多?我猜是這樣的。對初級用戶來說,他們看到的是 Vim 的模式編輯更省力,不累手。對喜歡折騰的用戶來說呢,他們想的是: 「哇靠,用 Python 就可以寫插件了啊那老子還學個毛的 Lisp?哪有 Python 的用處大啊 !」 於是就一窩蜂去用 Vim 了。Lisp 的美只有少數精英才能欣賞,大部分程序員只是一群趨炎附勢的人。而那些不想折騰,想開箱就有眾多插件可選的人,就用 Emacs。
現在,又有人覺得 Vim 太過保守,想要用 「下一代」 的 neoVim 取而代之。到底能不能真正成為 「下一代」,還是拭目以待吧。我也希望 Vim 能添一些新特性,但基本上對現在的 Vim 還是滿意的。
---- 補記: 我知道兩個很流行的 Vim 插件,YouCompleteMe 和 Conque,是用 Python 寫的。
---- 我的另一個答案: 如何用vim的插件開發,大家有什麼實際中的技巧么? - Jacky Liu 的回答
-- 完 --
1. Elise 並不特別 Lisp;相對於 Common Lisp 和 Scheme 而言;所以 Lisp 黨頭不頂青天
2. 很長一段時間 .el 解釋和 .elc 執行都沒有很慢;編輯文字這種事情就是圖一個爽怎麼能夠等程序呢
3. Vi 默認安裝
4. 即使有 emacs;ssh 執行遠端的 emacs 感覺很蛋疼(主要是和用 ssh 的 terminal 搶 key太酸爽了)
5. 因為你的問題局限於人類,而 emacser 大部分是多附肢生物和 19 世紀紡織女工的幽靈。比如下面才是一個典型的 emacser1.前面很多人提到了,發行版預裝上 Vi 的預裝要遠遠多於emacs,我覺得這個是根本原因之一,我最早不用 Vim 的時候,偶爾編輯一下東西也會 Vi,nano 那種玩意太難用了,如果是伺服器環境我再裝一個emacs也太麻煩,久而久之最熟悉的就是 Vi 這套東西。
2.Vim 的配置要比emacs容易太多,elisp 是一種健全的語言,功能確實很強大,但是不適合新手上手,Vim 的配置容易太多。
3.我用過幾個月emacs,天天手疼。我覺得Vim更好, emacs看似強大,實際上Vim更強大,可以看看SpaceVim的實現。
http://spacevim.org如果是我的話,因為老婆不會emacs,只會vim,所以我只能學vim了。後來我還是換成了收費軟體clion,vim還是太苦逼了。
我用emacs,圖中的學習曲線不是開玩笑。
vim可以上溯到ed,是根正苗紅的典型的unix程序,追求的是功能少而專註。而emacs是被unix幹掉了的lisp machine的亡靈,是典型的反unix設計的產物,力圖架空unix,把unix當lisp machine玩。所以除了某些b格特別高的人,正常的unix用戶實在沒必要用vim以外的任何編輯器。
作為一個玩了Emacs 3年的人,先佔坑。-----------2015-12-28----------添加慢慢補充。對vim不熟,以下vim代指vi系列。vim是很多系統發行版自帶,並且vim默認快捷鍵就很夠用了,配置文件可移植性高。對大文件支持無壓力。至於Emacs,就有很多值得吐槽的地方了。
- 配置文件不折騰根本不爽,快捷鍵也是要自己設才舒服,調教配置文件難。
- 配置文件還用的是函數式編程Elisp,想自己寫點函數,門檻也不低。
- 一些功能需要其他命令行支持,如aspell, clang, 這使得在瘟到死上或無外網的*nix上使用也很痛苦。
- Emacs自帶的包管理EPLA直到version 24才有,許多伺服器自帶源的版本沒這麼高。有許多包在CLI下不能用/不好看。進一步增加在伺服器上使用Emacs的難度。(當然,tramp或sshfs會有些用)
- 打開一個大文件(幾十M就算大了),卒。
當然了,這是一個披著文本編輯器的操作系統,所以用熟了還是相當爽的。
因為某教程里寫著:emacs是一款功能極其強大的編輯器,被公認為程序員最喜歡的代碼編輯器之一。打開它的第一步是:alias emacs=vim
其實原因可能真的是大部分unix系統計都自帶vim而emacs不是,這是不是算一種印隨現象?
1. 學校裡面跟linux相關的課程,好像編輯文件普遍都教大家用vim。
2. 學習曲線。3. @豆正三 先生提到的先入為主。4. 國內訪問Melpa等源好像比較慢,下載各種充滿奇技淫巧的elisp包要下半天。(可能不同地方不同網不一樣吧)5. 多種原因導致沒有折騰的慾望了。(據說掌握Emacs需要10年?)----------------------------------------------------------------------看有很多人說小指疼,我從來不用左手小指按Ctrl的,我Ctrl是用左手大拇指按的。我的左手小指負責Tab,Shift,左手大拇指負責Ctrl,Alt,?補充(左手拇指按Ctrl示意圖):側視圖:俯視圖:敲個代碼像玩拳皇一樣,太難。
個人學習經歷是vim先入為主吧,剛剛開始玩linux接觸的就是vim,好不容易配置舒服了,就繼續用了。其實我有嘗試用emacs,但是總感覺不順手。。
你上面說了一堆就是想表達Emacs更好嘛,但是你忽略了一個編輯器最重要的一點,那就是編輯。就文本編輯這個功能來說,我還沒有找到比vim更好用的工具。
推薦閱讀:
※vim8發布有一年了,有沒有基於vim8新特性開發的黑科技插件?
※Linux裡面的vim做什麼用的?我在terminal裡面輸入vi進入vi編輯器,可是不知道這個編輯器能實現什麼功能?
※如何讓vim像網頁一樣按Ctrl+放大字型大小?
※在xshell等終端上看c++代碼用哪些插件更加方便?
※有沒有vim學習,經典,權威,完整的書?