用vscode替代vim可行嗎？

感謝那麼多人給我解答，我已經放棄vim了，目前對vim就學學基礎的使用，改改配置用下，因為我之前嘗試用vscode打開系統配置文件竟然打不開？！

伺服器的話大工程都是pycharm遠程部署在本地修改，美滋滋。

vscode主要用來寫寫小腳本，編輯下文檔了

…………………分割線………………………………………………

最近學linux，vim這種命令式編輯真是太折磨人了，很多人說用習慣了就很高效。。。可是我感覺把vim用6得好久，所以我想問下用vscode替代vim可行嗎？我覺得vim能做的vscode都能做，有沒有用vim的大神告訴我一個不用vscode一定要學vim的理由？

沒有的話我就放棄vim了。。。。。。。。。

Vim 和 vscode 這兩個項目目標人群還是有差異的，vscode 更多的是面向常規的桌面用戶。他的生態也非常好，社區也很活躍。但是 vim 肯定有他存在的優勢，不然這麼多年也不會一直不被淘汰。對於終端用戶，vim 無疑是最好的編輯器。Vim 的優勢在於他的模式化編輯，這種模式化賦予了鍵盤中間區域的按鍵更多的功能，熟悉了這種模式後，會大大提高編輯速度，當然，編程速度不僅僅由編輯速度決定的。

對於 Vim 入門可能被網路妖魔化了，其實沒有網上傳言的那麼陡峭，他的曲線應該是豎折的z，前期比較舒緩，中期陡峭，後期也很舒緩。前期基本上1-2小時入門，基本操作基本可以掌握，再花幾周時間習慣這種模式，後期進階其實可以藉助幫助文檔，按需進階。

什麼是按需進階，是根據自己需要的功能，來查詢相關幫助。比如，我需要排序文件內容，看下 :h sort, 我需要查閱所有快捷鍵，看下 :h index。

前期，其實入門非常簡單，可以參閱我翻譯的 Vim 教程：

github.com

按照輪子哥所說，使用 vim 比較大的消耗是：「而這些編程環境都有簡單易配置的語言支持插件（比如語法高亮、智能補全、語法檢查等等），比你從零開始配置 vim 要容易得多。」 所以我才造了 SpaceVim，你可以想常規IDE那樣，簡單地在配置文件里啟用某個語言模塊就能搭建該語言的開發環境。我希望更多的人可以參與進來一起維護語言模塊。

Vim 相關的專欄收集如下：

zhuanlan.zhihu.comVim?

zhuanlan.zhihu.comVimer 的故事?

zhuanlan.zhihu.com玩轉 vim 與 Terminal (視頻)?

zhuanlan.zhihu.comVim?

zhuanlan.zhihu.comvimer?

zhuanlan.zhihu.com

Vim 的界面定製，也是比較自由，基本上可以說是想怎麼定製就怎麼定製。分享下我的 Vim 界面：

這張圖，當然是也是 SpaceVim 的截圖，如果你有興趣使用 SpaceVim，或者目前正在使用 SpaceVim, 可以來 SpaceVim 中文聊天室與我們一起交流，主要是討論 SpaceVim 一些特性和使用技巧：

gitter.im

突然發現自己新建了四個 vim 群，最多的裡面快2000人了。

• 121056965 （滿員）
• 755208473
• 748697811
• 667379969

現在來說，其實只要某個編輯器可擴展性強，自帶擴展語言，基本沒什麼功能東西是做不出來的。

關鍵是vim/emacs這樣的編輯器你突然想到什麼自動化的一個方法你可以馬上寫一兩行就搞出來，然後就用，正因為反饋周期很短，基本是個全民寫邏輯的感覺。

但是VS code的絕大多數用戶都是光弄別人的插件去了，然後自己最多調一下按鍵，搞一下json配置文件，最多也就是到這個地步。

而大多vim/emacs 用戶基本上都把別人的插件拿過來以後這裡改改，那裡弄弄，到最後成了自己的一套了。可能VS code 也有快速搞兩行邏輯然後應用的方法，但是至少我看到的大多數用戶不是這樣用的，vim和emacs的用戶是這樣用的。

其實這個也是我為什麼不看好 xi-editor的原因，他們相信寫native插件比支持一個腳本好，但是這樣的話，反饋周期長，那些喜歡搗騰的用戶還是會覺得vim/emacs這樣的東西順手，想到什麼就在配置文件里搞兩行然後看效果，甚至emacs可以讓你直接在當前文件對lisp表達式求值，覺得用得爽就往配置里丟，腦子裡想到什麼就可以快速應用，幾年積累下來就是自己最順手的東西（不知道vim是不是也有這樣的功能，好久沒用了，現在叛逃到隔壁用evil）。

.

這視乎你用 vim 來幹什麼，如果只寫代碼，視乎你寫的是什麼，前端顯然是沒問題的，後端的完全沒有接觸過不清楚。

我很早之前就已經不用 vim 寫代碼了，因為編程需要用到的 vim 式編輯操作目前主流 editor 或者 IDE 的 vim 模式插件基本都能滿足了（比如 HJKL、f{char}、n motion、dDyYpPoOtT 還有組合操作比如 dt&< 、d2f" 、di} 之類），大部分時候我們都用不上 vim 的那些高級的編輯功能（比如 global 命令）。而這些編程環境都有簡單易配置的語言支持插件（比如語法高亮、智能補全、語法檢查等等），比你從零開始配置 vim 要容易得多。

但如果你的 vim 是用來做文本處理的（而不是寫代碼），那 vscode 還是不行的。

vim 的文本編輯功能依然沒有什麼軟體能出其右，當你要全面整理一個小的既有的文檔（比如幾百 KB 、幾十 MB 的，我相信這不是通常編程工作的需求），而且需求比較複雜和多變——典型如小說文本——那麼現階段沒有比 vim 更好的可視化工具（當然你可以 cat 一部分出來看然後用 awk 、prel 、sed 等等摸黑編輯）。

比如我需要把全形數字全部換成半形的，那麼我寫個命令就行了：

silent%s/[１２３４５６７８９０]/={１:1,２:2,３:3,４:4,５:5,６:6,７:7,８:8,９:9,０:0}[submatch(0)]/ge


需要重複利用，就包成一個函數：

function FunctionName()
silent %s/[１２３４５６７８９０]/={１:1,２:2,３:3,４:4,５:5,６:6,７:7,８:8,９:9,０:0}[submatch(0)]/ge
endfunction


然後放到 vimrc 或者做成一個簡單的 vim 插件隨時調用。而在 vscode 之類的編輯器中做這件事情就很麻煩，一是沒有那麼簡單的 vim script 可以用，二是沒法像 vim 那麼隨意把命令寫到 .vim 文件中往插件目錄一放就行了。

比如一個小說的標題是這樣編的，還有很多錯：

第一層 &<== 正確的標題 第2層 &<== 寫成了阿拉伯數字 第三 層 &<== 手殘後面多了個空格 第4四層 &<== 手殘打多了個阿拉伯數字

你事先準備好的替換腳本多半沒辦法自動處理這些情況，你不得不手動來清理這些錯誤的時候，vim 做起來就會方便得多：

/^第.{-}層 " 搜索全部標題
n " 逐個檢查
cw&er&&& " cw刪掉`2`，切換出輸入法輸入`二`，把輸入法關掉，回到普通模式
n " 跳到下一個
f_x " _ 代表空格（space）
n " 跳到下一個
f4x " 刪掉4


還有的小說，部分章節標題的插圖放到標題上面了，應該是放下面的，而有的沒有錯。要命的是，有的內文插圖就是放在章節結尾的：

&
&序章& &baalaaaabalabalabalbalblabalablabla& &balabalabalabalbalblabalablabla& &balabalabalabalbalblabalablabla& &balabalabalabalbalblabalablabla& &
&第一章& &
&bbalabalabalabalbalblabalablabla& &balabalabalabalbalblabalablabla& &balabalabalabalbalblabalablabla& &balabalabalabalbalblabalablabla& &
&第二章& &balabalabalabalbalblabalablabla& &balabalabalabalbalblabalablabla& &balabalabalabalbalblabalablabla& &balabalabalabalbalblabalablabla&

所以你沒法簡單地寫個命令來處理：

:%s`^(&)
(&.*&)`2
1`g


當只能手工做的時候，我習慣的方式是：

/^&& " 找& qq " 錄一個宏，qq因為方便按，是錄製臨時宏的好方法
kddp " 上一行，刪掉，貼回來
q " 結束錄製
n " 找下一個，看看是不是要改的
@q " 重複之前執行的宏
n " 找下一個
@@ " 重複上一個@操作


vscode 之類的 vim 模擬插件是不允許你做這種操作的。而如果你用 awk 、sed 來操作，只能搞得你想死。

vscode從軟體質量上說肯定是可以替代vim的，但是和emacs相比則不一定。

vim一直做到8.1才把終端和非同步支持搞齊活，至少落後了隔壁emacs十幾年。gdb集成一直到2018年也沒什麼通行的方案，大量的人反覆造輪子。bram性格頑固，非要把vim做成自己的個人項目，拖到死不加這幾個大家呼喚了20年的feature，要不是nvim在一邊催著，大家估計現在還在用vim7.4。

說白了，這不是新老編輯器的架構理念高低，而是開發團隊與個人的態度問題。隔壁的emacs本身比vim還老，但代碼注釋清晰，各種前後端分離架構，c/s插件機制，lsp協議，調試集成功能一個也不缺呀。至於gui部分，一個electron的應用，也不至於比emacs高明到哪去吧？

有，比如你不得不在遠程伺服器上運行一個編輯器的時候。