https://www.zhihu.com/question/22867204
兼容VIM模式
這無疑團結了一大班 Vim過來的用戶，Sublime雖然也有VIM模式，但是Sublime在 mac下面的vim模式有bug，我習慣用 hjkl來移動光標，sublime再mac下hjkl移動有問題，且我習慣CTRL_[來返回NORMAL，手指不離開主鍵盤區，而sublime的vim模式只支持ESC返回，加上其作者經常神祕消失，最穩定的2.x版本已三年沒有更新，這些問題一直得不到修正。
由於Atom的定製程度直追 Vim/Emacs，它的vim模式能夠使用插件來實現，而不像sublime必須builtin，Atom的VIM模式除了官方實現外還有很多用戶實現，各有所長，你不喜歡可以換，Sublime就傻逼了，覺得builtin的不行，你就沒辦法了，而且作者不更新你也沒辦法。
Atom裏的Vim模式並不是強制的，你可以用也可以不用，這樣入門用戶也不會覺得困難，但是如果你用慣Vim的話，使用Vim模式可以取得更好的效率，我覺得Vim/Atom-VimMode能夠提升效率的地方有以下三方面：
1. 手指不離開主鍵盤區：
所有功能皆能在主鍵盤區完成，不用去按方向鍵，不用把手挪去按Home/End，更不用動鼠標。就像詠春中強調中線理論，認爲一切動作圍繞中軸線開展，守護自己中軸線的同時攻擊別人的中軸線。Vim/Atom-VimMode中，雙手不但從不離開主鍵盤，並且八根手指隨時守護再HOME位（ASDF, JKL;）有動作就移動，然後馬上歸位。
2. 細粒度微操作：
星際/dota玩的好，微操基本功，微操又快又精確，Vim/Atom-VimMode一樣，比如：
很多人編碼時習慣“成對編碼”，寫了申請資源的代碼，先把釋放資源寫了，寫了左括號，先把右括號給補充完，當你寫完第二行代碼時，需要用到“再1-2行中間插入一行”，此時你的光標停留在第二行，傳統編輯器你需要：按上箭頭移動光標到第一行 -> 按END鍵去到第一行末尾 -> 按回車插入一行，mac下的END鍵還需要用CMD+右來組合出來，而Vim/Atom-VimMode中，你只需要shift+o即可，手指完全不離開主鍵盤區，不用像傳統編輯器那樣，右手先移動到箭頭區又移動到HOME的小鍵盤區，再移動回主鍵盤區這麼麻煩，類似還有：
使用o直接再下一行插入，避免 END/回車
使用I再行首插入，避免移動半天光標。
向前/後移動一個單詞到單詞頭、尾。
快速更改當前單詞，用/來快速搜索移動光標。
dd+p來快速移動代碼塊，取代shift+方向鍵半天。
shift-j 來兩行合併成一行，代替 HOME, back 若干次。
。。。
你再編輯代碼的時候，90%的情況可以直接一步完成，這就叫細粒度微操，而且整個過程手都不需要離開主鍵盤，不像傳統編輯器那樣，若干笨重的操作組合再一起，操作不夠細步驟多的同時手還要再：主鍵盤區，方向鍵區，擴展鍵區 來回移動，效率奇低。而Vim/Atom-VimMode下，手指隨時守護在home區（ASDF JKL；），所有微操都是圍繞HOME區進行，不會移動到任何主鍵盤以外的區域，更別說用鼠標、觸摸板。
3. 批量操作：
比如要給下面代碼每行後面加一個分號：
一般做法是：移動光標到行末->END->分號->移動光標到下一行，Vim裏面不需要移動光標到行末，只需循環敲入：“A;<ESC>j” 即可，本來操作就少很多。這還不是最少操作，更少操作是利用Vim裏面的句號“.”功能重複上一次操作，即第一行“A;”補充了一個分號後，第二行只需要按一下"."即可重複，於是最後操作變爲：
第一行：A;<ESC>
後面所有行：J.
超級爽快的操作，這樣的操作還很多，你還可以單條命令對一萬行代碼重複上述步驟，或者把c代碼拷貝到go裏面先一句話把所有分號給刪除了。Vim下面的名言：絕不重複。
總之如果你熟悉 VIM模式，用 Atom能感到完全自由的方式，隨心所欲的書寫代碼，而不是被書寫這件事情費腦筋，解放大腦完全用於思考而不用於打字。但是同時對不習慣VIM的人照樣友好，或者對想使用VIM的便利卻又痛恨VIM這個軟件的簡陋的人帶來了福音。
這無疑團結了一大班 Vim過來的用戶，Sublime雖然也有VIM模式，但是Sublime在 mac下面的vim模式有bug，我習慣用 hjkl來移動光標，sublime再mac下hjkl移動有問題，且我習慣CTRL_[來返回NORMAL，手指不離開主鍵盤區，而sublime的vim模式只支持ESC返回，加上其作者經常神祕消失，最穩定的2.x版本已三年沒有更新，這些問題一直得不到修正。
由於Atom的定製程度直追 Vim/Emacs，它的vim模式能夠使用插件來實現，而不像sublime必須builtin，Atom的VIM模式除了官方實現外還有很多用戶實現，各有所長，你不喜歡可以換，Sublime就傻逼了，覺得builtin的不行，你就沒辦法了，而且作者不更新你也沒辦法。
Atom裏的Vim模式並不是強制的，你可以用也可以不用，這樣入門用戶也不會覺得困難，但是如果你用慣Vim的話，使用Vim模式可以取得更好的效率，我覺得Vim/Atom-VimMode能夠提升效率的地方有以下三方面：
1. 手指不離開主鍵盤區：
所有功能皆能在主鍵盤區完成，不用去按方向鍵，不用把手挪去按Home/End，更不用動鼠標。就像詠春中強調中線理論，認爲一切動作圍繞中軸線開展，守護自己中軸線的同時攻擊別人的中軸線。Vim/Atom-VimMode中，雙手不但從不離開主鍵盤，並且八根手指隨時守護再HOME位（ASDF, JKL;）有動作就移動，然後馬上歸位。
2. 細粒度微操作：
星際/dota玩的好，微操基本功，微操又快又精確，Vim/Atom-VimMode一樣，比如：
if (xxxx) {
}
使用o直接再下一行插入，避免 END/回車
使用I再行首插入，避免移動半天光標。
向前/後移動一個單詞到單詞頭、尾。
快速更改當前單詞，用/來快速搜索移動光標。
dd+p來快速移動代碼塊，取代shift+方向鍵半天。
shift-j 來兩行合併成一行，代替 HOME, back 若干次。
。。。
你再編輯代碼的時候，90%的情況可以直接一步完成，這就叫細粒度微操，而且整個過程手都不需要離開主鍵盤，不像傳統編輯器那樣，若干笨重的操作組合再一起，操作不夠細步驟多的同時手還要再：主鍵盤區，方向鍵區，擴展鍵區 來回移動，效率奇低。而Vim/Atom-VimMode下，手指隨時守護在home區（ASDF JKL；），所有微操都是圍繞HOME區進行，不會移動到任何主鍵盤以外的區域，更別說用鼠標、觸摸板。
3. 批量操作：
比如要給下面代碼每行後面加一個分號：
var x = 1
var y = 2
var z = 3
console.log('result is ' + (x + y + z).toString())
第一行：A;<ESC>
後面所有行：J.
超級爽快的操作，這樣的操作還很多，你還可以單條命令對一萬行代碼重複上述步驟，或者把c代碼拷貝到go裏面先一句話把所有分號給刪除了。Vim下面的名言：絕不重複。
總之如果你熟悉 VIM模式，用 Atom能感到完全自由的方式，隨心所欲的書寫代碼，而不是被書寫這件事情費腦筋，解放大腦完全用於思考而不用於打字。但是同時對不習慣VIM的人照樣友好，或者對想使用VIM的便利卻又痛恨VIM這個軟件的簡陋的人帶來了福音。
深度可定製系統
Vim/Emacs的精髓在於：“可以調教”，本來不順手的東西，只要容易調教，假以時日，都會慢慢變得越來越順手，越來越“懂你”，越來越“貼心”，以至於後面大家都離不開它了。而 Atom 也同樣是一款容易被你調教的編輯器。先前給vim寫過插件，給sublime寫過插件，如今給Atom寫過插件，橫向對比下來，幾個結論：
插件能做事情多少：Atom > Vim >> sublime
插件開發學習門檻：Vim > Atom > sublime
插件開發文檔豐富：Atom > sublime >> Vim
Atom 的定製化程度遠遠高過sublime之類（不用實際看法，看看雙方開發文檔即可），直追 Vim / Emacs，sublime的大部分定製無外乎改改json，插件能做的事情相當有限。
Atom 的定製化系統主要有三方面：
1. 細緻：
設計之初就考慮的事情，方方面面都能定製，見官方文檔，以及插件：vim-mode，minimap （稍微瞭解下這兩個類似的功能再 Atom 和 sublime的實現就能知道 sublime被甩了多少條街了）。可以細粒度的控制編輯器內所有行爲，小到移動一下光標，刪除當前一個字符，大到打開一個面板，比如 “core:more-up” 可以向上移動一行光標，“window:focus-pane-on-left” 可以把焦點設置到左邊的面板，atom內核和大量第一方第三方packages 都是以命令的方式把基礎功能提供出來，你可以隨意互相調用或者設置熱鍵。
除去命令外的API層面，幾乎每個部件每個像素點都可控，比如這樣的插件你永遠無法再 Vim / Emacs / Sublime 下面見得到：activate-power-mode。
2. 直觀：
由於使用 javascript/coffee進行開發，但 javascript/coffee是屬於即便你沒寫過他們，讀都能讀得懂，VimScript就不一樣了，雖然也能做相同的事情，但實話實說，晦澀難寫，比如我要取得當前文件的路徑和文件名，在 VimScript裏面需要這麼寫：
而在 Atom 裏我們用atom自己的功能直接取出路徑來，然後進行切割：
就問大家一下？哪段代碼更友好直觀？你一眼就知道在做什麼？你更願意用按照哪段代碼進行插件開發？是上面的VimScript？還是下面的 javascript ？
結論是很清晰的，Atom的 javascript開發插件更簡單直觀，即便沒文檔，看別人怎麼寫的自己也會了，同時靈活性大大高於VmScript，各種事件處理回調，javascript天生擅長做這些事情，還有第二行，第三行，我們用到了 node.js 的 path模塊，進行文件路徑切割。這樣的寫法，再VimScript 裏面基本是無法想象的。
Vim是強大，但是畢竟是30年前的東西了，即便最熟練的 Vimer 也都承認 VimScript 的晦澀難懂，阻礙了很多人爲其開發插件。而給Atom開發插件，只需要掌握javascript，掌握 javascript的人很多，學習了javascript你也可以用在很多地方。不像VimScript那樣只能用在Vim裏面，而正因爲其晦澀，Vim新版本開始支持內嵌 python的寫法：
VimScript中 Python等動態的支持正是說明其開發維護者也承認 VimScript本身的古老，對比現代編程語言已經有些格格不入了，缺乏強大的描述能力，難以構建複雜的功能模塊，纔會去支持Python內嵌這樣的寫法。可大量的工作還是需要再Python之外完成，同時，並非所有平臺自帶的Vim都支持python，除了mac外，所有debian / ubuntu 發行版自帶的Vim都不支持 Python。導致你想寫一個通用的擴展還得判斷下是否 has('python') 沒有的話老老實實用 VimScript 去實現它，這不是折磨人麼？
Sublime裏面可以用原生 Python 寫擴展，比 VimScript爽，但是 sublime 的插件能做的事情還不及VimScript的一半，所以怎麼能指望他們能寫出高端的功能來呢？
3. 強大：
Atom的內核 Electron （原來的 Atom-shell）可以理解成：Chromium + Node.JS，而整個Atom的界面，你可以理解成就是一顆 HTML 的 DOM 樹結構，這意味着你可以這樣：
就可以簡單的在 atom 裏面增加一個顯示對象，這意味着再給div加個 html的 onclick就可以實現GUI交互，界面上的對象隨便寫點html代碼就可以控制效果，意味着你可以使用 jQuery 來爲atom增加新面板，意味着你只需要寫一個簡單的 .css 文件就可以把 Atom 整個編輯器的外觀給修改了。這在 Vim/Emacs 中是幾乎不可想象的事情，sublime基本就別提了。
大量的前端開發技術和 Node.JS 基礎模塊供你任意使用，正是由於近年 Chromium / node.js 系列技術的成熟，和 Atom / Visual Studio Code 這類基於前端技術的客戶端軟件的成功，讓我看到了客戶端（桌面+移動）軟件開發的新方向。
Vim/Emacs的精髓在於：“可以調教”，本來不順手的東西，只要容易調教，假以時日，都會慢慢變得越來越順手，越來越“懂你”，越來越“貼心”，以至於後面大家都離不開它了。而 Atom 也同樣是一款容易被你調教的編輯器。先前給vim寫過插件，給sublime寫過插件，如今給Atom寫過插件，橫向對比下來，幾個結論：
插件能做事情多少：Atom > Vim >> sublime
插件開發學習門檻：Vim > Atom > sublime
插件開發文檔豐富：Atom > sublime >> Vim
Atom 的定製化程度遠遠高過sublime之類（不用實際看法，看看雙方開發文檔即可），直追 Vim / Emacs，sublime的大部分定製無外乎改改json，插件能做的事情相當有限。
Atom 的定製化系統主要有三方面：
1. 細緻：
設計之初就考慮的事情，方方面面都能定製，見官方文檔，以及插件：vim-mode，minimap （稍微瞭解下這兩個類似的功能再 Atom 和 sublime的實現就能知道 sublime被甩了多少條街了）。可以細粒度的控制編輯器內所有行爲，小到移動一下光標，刪除當前一個字符，大到打開一個面板，比如 “core:more-up” 可以向上移動一行光標，“window:focus-pane-on-left” 可以把焦點設置到左邊的面板，atom內核和大量第一方第三方packages 都是以命令的方式把基礎功能提供出來，你可以隨意互相調用或者設置熱鍵。
除去命令外的API層面，幾乎每個部件每個像素點都可控，比如這樣的插件你永遠無法再 Vim / Emacs / Sublime 下面見得到：activate-power-mode。
2. 直觀：
由於使用 javascript/coffee進行開發，但 javascript/coffee是屬於即便你沒寫過他們，讀都能讀得懂，VimScript就不一樣了，雖然也能做相同的事情，但實話實說，晦澀難寫，比如我要取得當前文件的路徑和文件名，在 VimScript裏面需要這麼寫：
let l:path = expand('%:p:h')
let l:name = expand('%:t:r')
或者
let l:name = expand('%<')
var fullpath =atom.workspace.getActiveTextEditor().getPath();
var filename = path.basename(fullpath);
var filepath = path.dirname(fullpath);
結論是很清晰的，Atom的 javascript開發插件更簡單直觀，即便沒文檔，看別人怎麼寫的自己也會了，同時靈活性大大高於VmScript，各種事件處理回調，javascript天生擅長做這些事情，還有第二行，第三行，我們用到了 node.js 的 path模塊，進行文件路徑切割。這樣的寫法，再VimScript 裏面基本是無法想象的。
Vim是強大，但是畢竟是30年前的東西了，即便最熟練的 Vimer 也都承認 VimScript 的晦澀難懂，阻礙了很多人爲其開發插件。而給Atom開發插件，只需要掌握javascript，掌握 javascript的人很多，學習了javascript你也可以用在很多地方。不像VimScript那樣只能用在Vim裏面，而正因爲其晦澀，Vim新版本開始支持內嵌 python的寫法：
python << EOF
import random
print random.randint(0,10)
EOF
VimScript中 Python等動態的支持正是說明其開發維護者也承認 VimScript本身的古老，對比現代編程語言已經有些格格不入了，缺乏強大的描述能力，難以構建複雜的功能模塊，纔會去支持Python內嵌這樣的寫法。可大量的工作還是需要再Python之外完成，同時，並非所有平臺自帶的Vim都支持python，除了mac外，所有debian / ubuntu 發行版自帶的Vim都不支持 Python。導致你想寫一個通用的擴展還得判斷下是否 has('python') 沒有的話老老實實用 VimScript 去實現它，這不是折磨人麼？
Sublime裏面可以用原生 Python 寫擴展，比 VimScript爽，但是 sublime 的插件能做的事情還不及VimScript的一半，所以怎麼能指望他們能寫出高端的功能來呢？
3. 強大：
Atom的內核 Electron （原來的 Atom-shell）可以理解成：Chromium + Node.JS，而整個Atom的界面，你可以理解成就是一顆 HTML 的 DOM 樹結構，這意味着你可以這樣：
var div = document.createElement("div");
div.innerText = "abc";
atom.workspace.addBottomPanel(div);
大量的前端開發技術和 Node.JS 基礎模塊供你任意使用，正是由於近年 Chromium / node.js 系列技術的成熟，和 Atom / Visual Studio Code 這類基於前端技術的客戶端軟件的成功，讓我看到了客戶端（桌面+移動）軟件開發的新方向。
做VIM/Emacs不能做的事情
Vim/Emacs過去給人的映像是：幾乎能做任何事情，確實如此，但畢竟是二三十年前的東西了，而他們一直堅挺到現在一方面是操作便利，更重要的是這麼長時間還沒有出現一款又開源又具備同樣操作便利性和可擴展性的編輯器，所以Vimer, Emacser 們最樂意展示給別人看的就是他們又安裝了什麼插件，急於展示可以把 Vim / Emacs 裝扮成了一個多像 IDE 的東西，而今天這個“可以做任何事情”的高度可定製特性已經被Atom所吸收並完全超越，就像 Atom 的開發blog：“ Introducing Atom” 上說的一樣，對易用性和可展性 “決不妥協” ：
Vim/Emacs即便大部分擴展功能也都可以稱爲“能用”，可幾十年的歷史包袱太沉，很多事情對他們來講就是禁區，比如詭異的標籤功能，容易誤操作的buffer/窗口切換，缺乏異步機制，編譯時間長只有傻等着，無法跟Atom一樣邊讀代碼，邊運行程序看結果，對照輸出結果和源代碼找問題，連實現個內嵌終端都用了若干年，還實現的那麼彆扭。。。。。。。。。
![]()
![]()
十分期待未來各種免費開源數學計算庫同atom稍微集成下，就可以讓你左邊寫一個等式，右邊圖表就能出來，是多麼爽的一種體驗啊？
Atom插件演示：color picker，快捷鍵打開取色面板，取完後直接生成代碼插入光標之後
&lt;img src="https://pic3.zhimg.com/50/fef27589c3f01e04a15ebe3499d33c0d_hd.jpg" data-rawwidth="446" data-rawheight="530" class="origin_image zh-lightbox-thumb" width="446" data-original="https://pic3.zhimg.com/fef27589c3f01e04a15ebe3499d33c0d_r.jpg"&gt;![]()
Atom插件演示：代碼中表示顏色的語句直接用該顏色上色，可以根據文件擴展名，對特定文件打開
&lt;img src="https://pic1.zhimg.com/50/8856d4daf930383f93e1e8688e20669f_hd.jpg" data-rawwidth="438" data-rawheight="375" class="origin_image zh-lightbox-thumb" width="438" data-original="https://pic1.zhimg.com/8856d4daf930383f93e1e8688e20669f_r.jpg"&gt;![]()
短短兩年的時間，這麼多優秀的插件，只想說，如今 Atom 作爲 Vim/Emacs 的繼承者和超越者出現了，所以社區對 Atom 的反應也是熱烈的，看看下面一組數據，截止今天（2016年3月15日），Atom共有擴展插件 3500+ 個，發佈不到兩年的時間，這是什麼概念呢？
Vim/Emacs過去給人的映像是：幾乎能做任何事情，確實如此，但畢竟是二三十年前的東西了，而他們一直堅挺到現在一方面是操作便利，更重要的是這麼長時間還沒有出現一款又開源又具備同樣操作便利性和可擴展性的編輯器，所以Vimer, Emacser 們最樂意展示給別人看的就是他們又安裝了什麼插件，急於展示可以把 Vim / Emacs 裝扮成了一個多像 IDE 的東西，而今天這個“可以做任何事情”的高度可定製特性已經被Atom所吸收並完全超越，就像 Atom 的開發blog：“ Introducing Atom” 上說的一樣，對易用性和可展性 “決不妥協” ：
We think we can do better. Our goal is a zero-compromise combination of hackability and usability: an editor that will be welcoming to an elementary school student on their first day learning to code, but also a tool they won't outgrow as they develop into seasoned hackers.
拋開易用性的這個 Atom 的明顯優勢不說，前面其實已說了不少 Atom 比 Vim/Emacs 更靈活強大的地方，可能有些人還有疑惑，不是說 Emacs “沒有不能做的事情” 麼？你看 Atom的面板裏面可以嵌入一個 Terminal，Vim/Emacs一樣可以嵌入啊，爲何還說 Atom 比它強啊？
沒錯，Vim用久了會產生心理舒適區，多模式編輯使人神清氣爽，命令化文本處理讓你賞心悅目，但是受限於本身機制用久了會容易痛苦掙扎：雖然vim的各種擴展似乎什麼事情都能做，但每個擴展卻只能做到70分，總有那麼30%的地方做不到位。所以用的時間長了，上半身爽的要死，下半身痛不欲生。。。。
Vim/Emacs即便大部分擴展功能也都可以稱爲“能用”，可幾十年的歷史包袱太沉，很多事情對他們來講就是禁區，比如詭異的標籤功能，容易誤操作的buffer/窗口切換，缺乏異步機制，編譯時間長只有傻等着，無法跟Atom一樣邊讀代碼，邊運行程序看結果，對照輸出結果和源代碼找問題，連實現個內嵌終端都用了若干年，還實現的那麼彆扭。。。。。。。。。
這類硬傷有許多，再舉個最簡單的例子，minimap，就是 sublime那種大家喜歡的文檔縮略圖，這個現代編輯器必備的功能，誰能用 Vim/Emacs 實現一下看看？Atom 可以衍生出 Visual Studio Code 這樣漂亮的編輯器，Vim/Emacs能衍生麼？Atom可以隨便用各種先進的前端技術，不當可以嵌 Terminal我甚至可以再 Atom 嵌入一個 js版本的 DOSBOX 玩老遊戲《命令與征服》：
https://archive.org/details/softwarelibrary_msdos_games
當然這樣並沒有任何卯用，但是如果在 Atom裏面內嵌一個瀏覽器，方便的實時預覽html/css的效果呢？或者 Atom 裏面內嵌一個 Markdown Previewer ，實時查看 Markdown 的效果呢？請問 Vim/Emacs 裏怎麼實現法？
Atom插件演示：markdown實時預覽，左邊寫右邊即時更新，100%兼容github的markdown語法
&lt;img src="https://pic4.zhimg.com/50/f675f9a730d82e8a583190d69c3a94bd_hd.jpg" data-rawwidth="1077" data-rawheight="692" class="origin_image zh-lightbox-thumb" width="1077" data-original="https://pic4.zhimg.com/f675f9a730d82e8a583190d69c3a94bd_r.jpg"&gt;
Atom插件演示：正則表達式圖形化，鼠標移動上去自動顯示
&lt;img src="https://pic1.zhimg.com/50/ac5335553d8cb1cebc5132921678fdb6_hd.jpg" data-rawwidth="600" data-rawheight="540" class="origin_image zh-lightbox-thumb" width="600" data-original="https://pic1.zhimg.com/ac5335553d8cb1cebc5132921678fdb6_r.jpg"&gt;
十分期待未來各種免費開源數學計算庫同atom稍微集成下，就可以讓你左邊寫一個等式，右邊圖表就能出來，是多麼爽的一種體驗啊？Atom插件演示：color picker，快捷鍵打開取色面板，取完後直接生成代碼插入光標之後
&lt;img src="https://pic3.zhimg.com/50/fef27589c3f01e04a15ebe3499d33c0d_hd.jpg" data-rawwidth="446" data-rawheight="530" class="origin_image zh-lightbox-thumb" width="446" data-original="https://pic3.zhimg.com/fef27589c3f01e04a15ebe3499d33c0d_r.jpg"&gt;
Atom插件演示：代碼中表示顏色的語句直接用該顏色上色，可以根據文件擴展名，對特定文件打開
&lt;img src="https://pic1.zhimg.com/50/8856d4daf930383f93e1e8688e20669f_hd.jpg" data-rawwidth="438" data-rawheight="375" class="origin_image zh-lightbox-thumb" width="438" data-original="https://pic1.zhimg.com/8856d4daf930383f93e1e8688e20669f_r.jpg"&gt;
短短兩年的時間，這麼多優秀的插件，只想說，如今 Atom 作爲 Vim/Emacs 的繼承者和超越者出現了，所以社區對 Atom 的反應也是熱烈的，看看下面一組數據，截止今天（2016年3月15日），Atom共有擴展插件 3500+ 個，發佈不到兩年的時間，這是什麼概念呢？
- Sublime的插件（Stats - Package Control）大概 3500+個，但是sublime發佈了5年的時間。
- Emacs 的插件大概有2900個，可Emacs發佈到今天已經過去 25+年的時間。
- Vim 的各種插件雖然有9000個，但是Vi/Vim系列的歷史長達 30+年，是atom的15倍。
性能優化
很多人錯誤的覺得 Atom慢是因爲使用了 JavaScript/Coffee 等 Web 技術，所以先天慢，其實這是個誤區，即便使用 Web 技術它也還能快很多，同時再慢可以往C++層的 Electron 挪啊，這也是這幾個版本優化的一些方向，基於 Atom 開發的 Visual Studio Code 可以那麼流暢， Atom 性能優化空間還很大，了不起多參考下自己的兒子，同樣開源的 vscode怎麼做的。
同時 Atom編輯器1.0版本以來性能得到了很大的提升，主要是兩個方面，一方面是js層的各種渲染優化，控件優化，延遲繪製，延遲加載，只繪製當前需要的東西等，另外一方面是將一些核心數據結構移動到 Electron 的 C++層，如今1.54版本性能較去年版本已經有了本質區別，運行時加載是慢些（但也比eclipse快很多），實際使用並沒覺得不如別的編輯器，況且，js層的優化和C層的優化未來還有很大的空間可以進步。
不過我不太喜歡 vscode 使用 Typed Script 進行開發，用點標準技術不行麼，Atom使用 JavaScript/Coffee 寫的多爽，如今 Atom 正在準備慢慢的切換到 JavaScript 的新標準 ES6 上。其次 vscode 快是快在“做的事情少”，主要是可擴展性方面的努力遠不及 Atom，插件機制相對弱智，所以 vscode 的社區如今還不是特別活躍，擴展也少，發佈一年多隻有差不多300+個擴展，遠不如 Atom 的情況，如果 vscode 還是按照現有結構開發下去，可能永遠不會擁有 Atom的靈活度，這樣再未來就無法擁有各種豐富多彩的插件。
同時 Atom編輯器1.0版本以來性能得到了很大的提升，主要是兩個方面，一方面是js層的各種渲染優化，控件優化，延遲繪製，延遲加載，只繪製當前需要的東西等，另外一方面是將一些核心數據結構移動到 Electron 的 C++層，如今1.54版本性能較去年版本已經有了本質區別，運行時加載是慢些（但也比eclipse快很多），實際使用並沒覺得不如別的編輯器，況且，js層的優化和C層的優化未來還有很大的空間可以進步。
不過我不太喜歡 vscode 使用 Typed Script 進行開發，用點標準技術不行麼，Atom使用 JavaScript/Coffee 寫的多爽，如今 Atom 正在準備慢慢的切換到 JavaScript 的新標準 ES6 上。其次 vscode 快是快在“做的事情少”，主要是可擴展性方面的努力遠不及 Atom，插件機制相對弱智，所以 vscode 的社區如今還不是特別活躍，擴展也少，發佈一年多隻有差不多300+個擴展，遠不如 Atom 的情況，如果 vscode 還是按照現有結構開發下去，可能永遠不會擁有 Atom的靈活度，這樣再未來就無法擁有各種豐富多彩的插件。