轉自： ?https://github.com/yangyangwithgnu/use_vim_as_ide

所需即所獲：像 IDE 一樣使用 vim

yangyangwithgnu@yeah.net
2016-03-30 16:39:33

【謝謝】

捐贈：支付寶?yangyangwithgnu@yeah.net?，支付寶二維碼（左），微信二維碼（右）

?

二手書：書，我提高開發技能的重要手段之一，隨著職業生涯的發展，書籍也在不斷增多，對我而言，一本書最多讀三遍，再往后，幾乎沒有什么營養吸收，這部分書對我已基本無用，但對其他人可能仍有價值，所以，為合理利用資源，我決定低價出售這些書，希望達到兩個目的：0）用售出的錢購買更多新書（沒當過雷鋒的朋友 (?′?`?)）；1）你低價購得需要的書（雖然二手）。到?https://github.com/yangyangwithgnu/used_books?看看有無你鐘意的。

【公告】

---

• 幫助：英譯版編制。github.com 上搜索 vim ide 關鍵字后第一匹配項便是本文，洋人瀏覽到本文的次數非常多，常常收到要求同步發表英文版的郵件，但是，你知道，這 80+ 頁的中文已經耗費我大量業余時間，所以，如果可能，希望有精力的朋友可以將其翻譯為英文，感謝！

• 討論：任何意見建議移步?http://www.v2ex.com/t/138696

【版本】

---

• v0.1.5，2016-03-30，新增/優化：0）采用 vundle 作為插件管理器，并統一采用各插件在 github.com 的地址；1）C++11/14 語法高亮插件從 STL-Syntax 換為 vim-cpp-enhanced-highlight，后者支持 STL 以及自行編寫函數、容器、模版等的高亮；2）接口文件（MyClass.h）與實現文件（MyClass.cpp）快捷切換的插件，從 a.vim 換為 vim-fswitch；3）增加標簽系統和語義系統的介紹；4）其他調整；
• v0.1.4，2016-02-16，優化：0）為規避快捷鍵前導字符重復導致操作等待的問題，優化光標快速移至行首/行尾的快捷鍵，優化結對符間快速移動的快捷鍵；1）增加代碼折疊的環境恢復。
• v0.1.3，2015-11-08，新增：0）光標快速移至行首的快捷鍵 lh 與光標右移鍵 l 沖突，導致光標左移操作等待，現添加 <Leader> 規避該問題；1）中文輸入狀態導致命令模式無效，借助插件解決該問題。
• v0.1.2，2015-01-18，新增：0）重寫“內容查找”，讓匹配項具備上下文提醒能力；1）“快速輸入結對符”擴充快速選中結對符內文本的相關知識；2）增加支持分支 undo 的介紹；3）增加持久化保存 undo 歷史的介紹；4）全文結構調整，將“內容查找”和“內容替換”移至“4 代碼分析”，將“快速輸入結對符”更名為“快速編輯結對符”，并移至“8 其他輔助”。
• v0.1.1，2014-12-27，新增/修正：0）重寫“代碼收藏”章節，停用過時的 visual mark，啟用用戶體驗更優的 vim-signature（@arcticlion，謝謝）；1）新增“基于語義的導航”章節，YCM 新增該項功能；2）調整“5.2 模板補全”章節結構，UltiSnips 不再提供預定義代碼模板；3）protodef 插件更新，修復 protodef 生成成員函數實現的返回語句錯誤的問題；4）給出安裝插件 vim-instant-markdown 的詳細步驟。
• v0.1.0，2014-10-13，新增。發布初始版本。

【目錄】

---

0 vim 必知會?
........0.1 .vimrc 文件?
........0.2 .vim/ 目錄?
1 源碼安裝編輯器 vim?
2 插件管理?
3 界面美化?
........3.1 主題風格?
........3.2 營造專注氛圍?
........3.3 添加輔助信息?
........3.4 其他?
4 代碼分析?
........4.1 語法高亮?
........4.2 代碼縮進?
........4.3 代碼折疊?
........4.4 接口與實現快速切換?
........4.5 代碼收藏?
........4.6 標識符列表?
................標簽系統?
................語義系統?
................基于標簽的標識符列表?
........4.7 聲明/定義跳轉?
................基于標簽的聲明/定義跳轉?
................基于語義的聲明/定義跳轉?
........4.8 內容查找?
........4.9 內容替換?
................快捷替換?
................精確替換?
5 代碼開發?
........5.1 快速開關注釋?
........5.2 模板補全?
........5.3 智能補全?
................基于標簽的智能補全?
................基于語義的智能補全?
........5.4 由接口快速生成實現框架?
........5.5 庫信息參考?
6 工程管理?
........6.1 工程文件瀏覽?
........6.2 多文檔編輯?
........6.3 環境恢復?
7 工具鏈集成?
........7.1 構建工具集成?
................代碼編譯?
................系統構建?
................一鍵編譯?
........7.2 靜態分析器集成?
8 其他輔助?
........8.1 快速編輯結對符?
........8.2 支持分支的 undo?
........8.3 快速移動?
........8.4 markdown 即時預覽?
........8.5 中/英輸入平滑切換?
9 尾聲

【正文】

---

開始前，我假設你：0）具備基本的 vim 操作能力，清楚如何打開/編輯/保存文檔、命令與插入模式間切換；1）希望將 vim 打造成 C/C++ 語言的 IDE，而非其他語言。

關于 vim 的優點，你在網上能查到 128+ 項，對我而言，只有兩項：0）所思即所得，讓手輸入的速度跟上大腦思考的速度，1）所需即所獲，只有你想不到的功能、沒有實現不了的插件。希望獲得前者的能力，你需要兩本教程深入學習，《Practical Vim: Edit Text at the Speed of Thought》和《vim user manual》；要想擁有后者的能力，通讀本文 -。-#。對于 vim 的喜愛，獻上濕哥哥以表景仰之情：

vi 之大道如我心之禪，
vi 之漫路即為禪修，
vi 之命令禪印于心，
未得此道者視之怪誕，
與之為伴者洞其真諦，
長修此道者巨變人生。 作：reddy@lion.austin.com
譯：yangyangwithgnu@yeah.net

言歸正傳，說說 vim 用于代碼編寫提供了哪些直接和間接功能支撐。vim 用戶手冊中，50％ 的例子都是在講 vim 如何高效編寫代碼，由此可見，vim 是一款面向于程序員的編輯器，即使某些功能 vim 無法直接完成，借助其豐富的插件資源，必定可以達成目標，這就是所需即所獲。 我是個目標驅動的信奉者，本文內容，我會先給出優秀 C/C++ IDE 應具備哪些功能，再去探索如何通過 vim 的操作或插件來達到目標。最終至少要像這個樣子：

（圖形環境下 IDE 總攬）
（純字符模式下 IDE 總攬）

0 vim 必知會

在正式開始前先介紹幾個 vim 的必知會，這不是關于如何使用而是如何配置 vim 的要點，這對理解后續相關配置非常有幫助。

0.1 .vimrc 文件

.vimrc 是控制 vim 行為的配置文件，位于 ~/.vimrc，不論 vim 窗口外觀、顯示字體，還是操作方式、快捷鍵、插件屬性均可通過編輯該配置文件將 vim 調教成最適合你的編輯器。

很多人之所以覺得 vim 難用，是因為 vim 缺少默認設置，甚至安裝完后你連配置文件自身都找不到，不進行任何配置的 vim 的確難看、難用。不論用于代碼還是普通文本編輯，有必要將如下基本配置加入 .vimrc 中。

前綴鍵。各類 vim 插件幫助文檔中經常出現 <leader>，即，前綴鍵。vim 自帶有很多快捷鍵，再加上各類插件的快捷鍵，大量快捷鍵出現在單層空間中難免引起沖突，為緩解該問題，引入了前綴鍵 <leader>，這樣，鍵 r 可以配置成 r、<leader>r、<leader><leader>r 等等多個快捷鍵。前綴鍵是 vim 使用率較高的一個鍵（最高的當屬 Esc），選一個最方便輸入的鍵作為前綴鍵，將有助于提高編輯效率。找個無須眼睛查找、無須移動手指的鍵 —— 分號鍵，挺方便的，就在你右手小指處：

" 定義快捷鍵的前綴，即<Leader> let mapleader=";"

既然前綴鍵是為快捷鍵服務的，那隨便說下快捷鍵設定原則：不同快捷鍵盡量不要有同序的相同字符。比如，<leader>e 執行操作 0 和 <leader>eb 執行操作 1，在你鍵入 <leader>e 后，vim 不會立即執行操作 0，而是繼續等待用戶鍵入 b，即便你只想鍵入 <leader>e，vim 也不得不花時間等待輸入以確認是哪個快捷鍵，顯然，這讓 <leader>e 響應速度變慢。<leader>ea 和 <leader>eb 就沒問題。

文件類型偵測。允許基于不同語言加載不同插件（如，C++ 的語法高亮插件與 python 的不同）：

" 開啟文件類型偵測 filetype on " 根據偵測到的不同類型加載對應的插件 filetype plugin on

快捷鍵。把 vim（非插件）常用操作設定成快捷鍵，提升效率：

" 定義快捷鍵到行首和行尾 nmap LB 0 nmap LE $ " 設置快捷鍵將選中文本塊復制至系統剪貼板 vnoremap <Leader>y "+y " 設置快捷鍵將系統剪貼板內容粘貼至 vim nmap <Leader>p "+p " 定義快捷鍵關閉當前分割窗口 nmap <Leader>q :q<CR> " 定義快捷鍵保存當前窗口內容 nmap <Leader>w :w<CR> " 定義快捷鍵保存所有窗口內容并退出 vim nmap <Leader>WQ :wa<CR>:q<CR> " 不做任何保存，直接退出 vim nmap <Leader>Q :qa!<CR> " 依次遍歷子窗口 nnoremap nw <C-W><C-W> " 跳轉至右方的窗口 nnoremap <Leader>lw <C-W>l " 跳轉至左方的窗口 nnoremap <Leader>hw <C-W>h " 跳轉至上方的子窗口 nnoremap <Leader>kw <C-W>k " 跳轉至下方的子窗口 nnoremap <Leader>jw <C-W>j " 定義快捷鍵在結對符之間跳轉 nmap <Leader>M %

立即生效。全文頻繁變更 .vimrc，要讓變更內容生效，一般的做法是先保存 .vimrc 再重啟 vim，太繁瑣了，增加如下設置，可以實現保存 .vimrc 時自動重啟加載它：

" 讓配置變更立即生效 autocmd BufWritePost $MYVIMRC source $MYVIMRC

比如，我可以隨時切換配色方案：

（配置變更立即生效）

其他。搜索、vim 命令補全等設置：

" 開啟實時搜索功能 set incsearch " 搜索時大小寫不敏感 set ignorecase " 關閉兼容模式 set nocompatible " vim 自身命令行模式智能補全 set wildmenu

以上的四類配置不僅影響 vim，而且影響插件是否能正常運行。很多插件不僅要在 .vimrc 中添加各自特有的配置信息，還要增加 vim 自身的配置信息，在后文的各類插件介紹中，我只介紹對應插件特有配置信息，當你發現按文中介紹操作后插件未生效，很可能是 vim 自身配置信息未添加，所以一定要把上述配置拷貝至到你的 .vimrc 中，再對照本文介紹一步步操作。.vimrc 完整配置信息參見附錄，每個配置項都有對應注釋。另外，由于有些插件還未來得及安裝，在你實驗前面的插件是否生效時，vim 可能有報錯信息提示，先別理會，安裝完所有插件后自然對了。

0.2 .vim/ 目錄

.vim/ 目錄是存放所有插件的地方。vim 有一套自己的腳本語言 vimscript，通過這種腳本語言可以實現與 vim 交互，達到功能擴展的目的。一組 vimscript 就是一個 vim 插件，vim 的很多功能都由各式插件實現。此外，vim 還支持 perl、python、lua、ruby 等主流腳本語言編寫的插件，前提是 vim 源碼編譯時增加 ---enable-perlinterp、--enable-pythoninterp、--enable-luainterp、--enable-rubyinterp 等選項。vim.org 和 github.com 有豐富的插件資源，任何你想得到的功能，如果 vim 無法直接支持，那一般都有對應的插件為你服務，有需求時可以去逛逛。

vim 插件目前分為 *.vim 和 *.vba 兩類，前者是傳統格式的插件，實際上就是一個文本文件，通常 someplugin.vim（插件腳本）與 someplugin.txt（插件幫助文件）并存在一個打包文件中，解包后將 someplugin.vim 拷貝到 ~/.vim/plugin/ 目錄，someplugin.txt 拷貝到 ~/.vim/doc/ 目錄即可完成安裝，重啟 vim 后剛安裝的插件就已經生效，但幫助文件需執行 :helptags ~/.vim/doc/ 才能生效，可通過 :h someplugin 查看插件幫助信息。傳統格式插件需要解包和兩次拷貝才能完成安裝，相對較繁瑣，所以后來又出現了 *.vba 格式插件，安裝便捷，只需在 shell 中依次執行如下命令即可：

vim someplugin.vba :so % :q

不論是直接拷貝插件到目錄，還是通過 *.vba 安裝，都不便于插件卸載、升級，后來又出現了管理插件的插件 vundle。

后面就正式開始了嘍，文中前后內容順序敏感，請依次查閱。

1 源碼安裝編輯器 vim

發行套件的軟件源中預編譯的 vim 要么不是最新版本，要么功能有閹割，有必要升級成全功能的最新版，當然，源碼安裝必須滴：

git clone git@github.com:vim/vim.git cd vim/ ./configure --with-features=huge --enable-pythoninterp --enable-rubyinterp --enable-luainterp --enable-perlinterp --with-python-config-dir=/usr/lib/python2.7/config/ --enable-gui=gtk2 --enable-cscope --prefix=/usr make make install

其中，--enable-pythoninterp、--enable-rubyinterp、--enable-perlinterp、--enable-luainterp 等分別表示支持 ruby、python、perl、lua 編寫的插件，--enable-gui=gtk2 表示生成采用 GNOME2 風格的 gvim，--enable-cscope 支持 cscope，--with-python-config-dir=/usr/lib/python2.7/config/ 指定 python 路徑（先自行安裝 python 的頭文件 python-devel），這幾個特性非常重要，影響后面各類插件的使用。注意，你得預先安裝相關依賴庫的頭文件，python-devel、python3-devel、ruby-devel、lua-devel、libX11-devel、gtk-devel、gtk2-devel、gtk3-devel、ncurses-devel，如果缺失，源碼構建過程雖不會報錯，但最終生成的 vim 很可能缺失某些功能。構建完成后在 vim 中執行

:echo has('python')

若輸出 1 則表示構建出的 vim 已支持 python，反之，0 則不支持。

2 插件管理

既然本文主旨在于講解如何通過插件將 vim 打造成中意的 C/C++ IDE，那么高效管理插件是首要解決的問題。

vim 自身希望通過在 .vim/ 目錄中預定義子目錄管理所有插件（比如，子目錄 doc/ 存放插件幫助文檔、plugin/ 存放通用插件腳本），vim 的各插件打包文檔中通常也包含上述兩個（甚至更多）子目錄，用戶將插件打包文檔中的對應子目錄拷貝至 .vim/ 目錄即可完成插件的安裝。一般情況下這種方式沒問題，但我等重度插件用戶，.vim/ 將變得混亂不堪，至少存在如下幾個問題：

• 插件名字沖突。所有插件的幫助文檔都在 doc/ 子目錄、插件腳本都在 plugin/ 子目錄，同個名字空間下必然引發名字沖突；
• 插件卸載易誤。你需要先知道 doc/ 和 plugin/ 子目錄下哪些文件是屬于該插件的，再逐一刪除，容易多刪/漏刪。

我希望每個插件在 .vim/ 下都有各自獨立子目錄，這樣需要升級、卸載插件時，直接找到對應插件目錄變更即可；另外，我希望所有插件清單能在某個配置文件中集中羅列，通過某種機制實現批量自動安裝/更新/升級所有插件。vundle（https://github.com/VundleVim/Vundle.vim?）為此而生，它讓管理插件變得更清晰、智能。

vundle 會接管 .vim/ 下的所有原生目錄，所以先清空該目錄，再通過如下命令安裝 vundle：

git clone https://github.com/VundleVim/Vundle.vim.git ~/.vim/bundle/Vundle.vim

接下來在 .vimrc 增加相關配置信息：

" vundle 環境設置 filetype off set rtp+=~/.vim/bundle/Vundle.vim " vundle 管理的插件列表必須位于 vundle#begin() 和 vundle#end() 之間 call vundle#begin() Plugin 'VundleVim/Vundle.vim' Plugin 'altercation/vim-colors-solarized' Plugin 'tomasr/molokai' Plugin 'vim-scripts/phd' Plugin 'Lokaltog/vim-powerline' Plugin 'octol/vim-cpp-enhanced-highlight' Plugin 'nathanaelkane/vim-indent-guides' Plugin 'derekwyatt/vim-fswitch' Plugin 'kshenoy/vim-signature' Plugin 'vim-scripts/BOOKMARKS—Mark-and-Highlight-Full-Lines' Plugin 'majutsushi/tagbar' Plugin 'vim-scripts/indexer.tar.gz' Plugin 'vim-scripts/DfrankUtil' Plugin 'vim-scripts/vimprj' Plugin 'dyng/ctrlsf.vim' Plugin 'terryma/vim-multiple-cursors' Plugin 'scrooloose/nerdcommenter' Plugin 'vim-scripts/DrawIt' Plugin 'SirVer/ultisnips' Plugin 'Valloric/YouCompleteMe' Plugin 'derekwyatt/vim-protodef' Plugin 'scrooloose/nerdtree' Plugin 'fholgado/minibufexpl.vim' Plugin 'gcmt/wildfire.vim' Plugin 'sjl/gundo.vim' Plugin 'Lokaltog/vim-easymotion' Plugin 'suan/vim-instant-markdown' Plugin 'lilydjwg/fcitx.vim' " 插件列表結束 call vundle#end() filetype plugin indent on

其中，每項

Plugin 'dyng/ctrlsf.vim'

對應一個插件（這與 go 語言管理不同代碼庫的機制類似），后續若有新增插件，只需追加至該列表中即可。vundle 支持源碼托管在?https://github.com/?的插件，同時 vim 官網?http://www.vim.org/?上的所有插件均在?https://github.com/vim-scripts/?有鏡像，所以，基本上主流插件都可以納入 vundle 管理。具體而言，仍以 ctrlsf.vim 為例，它在 .vimrc 中配置信息為 dyng/ctrlsf.vim，vundle 很容易構造出其真實下載地址?https://github.com/dyng/ctrlsf.vim.git?，然后借助 git 工具進行下載及安裝。

此后，需要安裝插件，先找到其在 github.com 的地址，再將配置信息其加入 .vimrc 中的call vundle#begin() 和 call vundle#end() 之間，最后進入 vim 執行

:PluginInstall

便可通知 vundle 自動安裝該插件及其幫助文檔。比如，我在 .vimrc 中添加了 4 個插件：

Plugin 'VundleVim/Vundle.vim' Plugin 'altercation/vim-colors-solarized' Plugin 'Lokaltog/vim-powerline' Plugin 'octol/vim-cpp-enhanced-highlight'

當前，.vim/ 為空，當我在 vim 中執行 :PluginInstall 時，整個自動安裝過程便開始了：

（vundle 批量安裝插件）

要卸載插件，先在 .vimrc 中注釋或者刪除對應插件配置信息，然后在 vim 中執行

:PluginClean

即可刪除對應插件。插件更新頻率較高，差不多每隔一個月你應該看看哪些插件有推出新版本，批量更新，只需執行

:PluginUpdate

即可。

你得注意插件的下載源。同名插件在 github.com 上可能有多個，比如，indexer 插件，至少就有?https://github.com/vim-scripts/indexer.tar.gz?、https://github.com/everzet/vim-indexer?、https://github.com/shemerey/vim-indexer?等三個，到底應該選哪個呢？以我的經驗來看，對于鐘意的插件，我會先找其作者的個人網站，上面通常會羅列出托管在 github.com 的具體地址；若沒有，我會找該插件在 vim.org 的頁面，上面也會有 github.com 托管地址；若還是沒有，再以 github 和插件名作為關鍵字搜索，點贊數多的，通常是你想找的。為節約你找插件地址的時間，本文中出現的每個插件我都會附上其地址。非特殊情況，后文介紹到的插件不再累述如何安裝。

通過 vundle 管理插件后，切勿通過發行套件自帶的軟件管理工具安裝任何插件，不然 .vim/ 又要混亂了。

3 界面美化

玉不琢不成器，vim 不配不算美。剛安裝好的 vim 樸素得嚇人，這是與我同時代的軟件么？

（默認 vim 界面）

就我的審美觀而言，至少有幾個問題：語法高亮太單薄、主題風格太簡陋、窗口元素太冗余、輔助信息太欠缺。

3.1 主題風格

一套好的配色方案絕對會影響你的編碼效率，vim 內置了 10 多種配色方案供你選擇，GUI 下，可以通過菜單（Edit -> Color Scheme）試用不同方案，字符模式下，需要你手工調整配置信息，再重啟 vim 查看效果（csExplorer 插件，可在字符模式下不用重啟即可查看效果）。不滿意，可以去?http://vimcolorschemetest.googlecode.com/svn/html/index-c.html?慢慢選。我自認為“閱美無數”，目前最夯三甲：

• 素雅 solarized（https://github.com/altercation/vim-colors-solarized?）
• 多彩 molokai（https://github.com/tomasr/molokai?）
• 復古 phd（http://www.vim.org/scripts/script.php?script_id=3139?）

在 .vimrc 中選用某個主題：

" 配色方案 set background=dark colorscheme solarized "colorscheme molokai "colorscheme phd

其中，不同主題都有暗/亮色系之分，這樣三種主題六種風格，久不久換一換，給你不一樣的心情：

（solarized 主題風格）

3.2 營造專注氛圍

如今的 UX 設計講究的是內容至上，從 GNOME3 的變化就能看出。編輯器界面展示的應全是代碼，不應該有工具條、菜單、滾動條浪費空間的元素，另外，編程是種精神高度集中的腦力勞動，不應出現閃爍光標、花哨鼠標這些分散注意力的東東。配置如下：

" 禁止光標閃爍 set gcr=a:block-blinkon0 " 禁止顯示滾動條 set guioptions-=l set guioptions-=L set guioptions-=r set guioptions-=R " 禁止顯示菜單和工具條 set guioptions-=m set guioptions-=T

重啟 vim 后效果如下：

（去除冗余窗口元素）

還容易分神？好吧，我們把 vim 弄成全屏模式。vim 自身無法實現全屏，必須借助第三方工具 wmctrl，一個控制窗口 XYZ 坐標、窗口尺寸的命令行工具。先自行安裝 wmctrl，再在 .vimrc 中增加如下信息：

" 將外部命令 wmctrl 控制窗口最大化的命令行參數封裝成一個 vim 的函數 fun! ToggleFullscreen()call system("wmctrl -ir " . v:windowid . " -b toggle,fullscreen") endf " 全屏開/關快捷鍵 map <silent> <F11> :call ToggleFullscreen()<CR> " 啟動 vim 時自動全屏 autocmd VimEnter * call ToggleFullscreen()

上面是一段簡單的 vimscript 腳本，外部命令 wmctrl 及其命令行參數控制將指定窗口 windowid（即，vim）全屏，綁定快捷鍵 F11 實現全屏/窗口模式切換（linux 下各 GUI 軟件約定使用 F11 全屏，最好遵守約定），最后配置啟動時自動全屏。

3.3 添加輔助信息

去除了冗余元素讓 vim 界面清爽多了，為那些實用輔助信息騰出了空間。光標當前位置、顯示行號、高亮當前行/列等等都很有用：

" 總是顯示狀態欄 set laststatus=2 " 顯示光標當前位置 set ruler " 開啟行號顯示 set number " 高亮顯示當前行/列 set cursorline set cursorcolumn " 高亮顯示搜索結果 set hlsearch

效果如下：

（添加輔助信息）

3.4 其他美化

默認字體不好看，挑個自己喜歡的，前提是你得先安裝好該字體。中文字體，我喜歡飽滿方正的（微軟雅黑），英文字體喜歡圓潤的（Consolas），vim 無法同時使用兩種字體，怎么辦？有人制作發布了一款中文字體用微軟雅黑、英文字體用 Consolas 的混合字體 —— yahei consolas hybrid 字體，號稱最適合中國程序員使用的字體，效果非常不錯（本文全文采用該字體）。在 .vimrc 中設置下：

" 設置 gvim 顯示字體 set guifont=YaHei\ Consolas\ Hybrid\ 11.5

其中，由于字體名存在空格，需要用轉義符“\”進行轉義；最后的 11.5 用于指定字體大小。

代碼折行也不太美觀，禁止掉：

" 禁止折行 set nowrap

前面介紹的主題風格對狀態欄不起作用，需要借助插件 Powerline（https://github.com/Lokaltog/vim-powerline?）美化狀態欄，在 .vimrc 中設定狀態欄主題風格：

" 設置狀態欄主題風格 let g:Powerline_colorscheme='solarized256'

效果如下：

（界面美化最終效果）

圖中，中英文混合字體看著是不是很舒服哈；增強后的狀態欄，不僅界面漂亮多了，而且多了好些輔助信息（所在函數名、文件編碼格式、文件類型）。

4 代碼分析

閱讀優秀開源項目源碼是提高能力的重要手段，營造舒適、便利的閱讀環境至關重要。

4.1 語法高亮

代碼只有一種顏色的編輯器，就好像紅綠燈只有一種顏色的路口，全然無指引。現在已是千禧年后的十年了，早已告別上世紀六、七十年代黑底白字的時代，即使在字符模式下編程（感謝偉大的 fbterm），我也需要語法高亮。所幸 vim 自身支持語法高亮，只需顯式打開即可：

" 開啟語法高亮功能 syntax enable " 允許用指定語法高亮配色方案替換默認方案 syntax on

效果如下：

（語法高亮）

上圖中 STL 容器模板類 unordered_multimap 并未高亮，對滴，vim 對 C++ 語法高亮支持不夠好（特別是 C++11/14 新增元素），必須借由插件 vim-cpp-enhanced-highlight（https://github.com/octol/vim-cpp-enhanced-highlight?）進行增強。效果如下：

（增強 C++11 及 STL 的語法高亮）

vim-cpp-enhanced-highlight 主要通過 .vim/bundle/vim-cpp-enhanced-highlight/after/syntax/cpp.vim 控制高亮關鍵字及規則，所以，當你發現某個 STL 容器類型未高亮，那么將該類型追加進 cpp.vim 即可。如，initializer_list 默認并不會高亮，需要添加

syntax keyword cppSTLtype initializer_list

4.2 代碼縮進

C/C++ 中的代碼執行流由復合語句控制，如 if(){} 判斷復合語句、for(){} 循環符號語句等等，這勢必出現大量縮進。縮進雖然不影響語法正確性，但對提升代碼清晰度有不可替代的功效。

在 vim 中有兩類縮進表示法，一類是用 1 個制表符（'\t'），一類是用多個空格（' '）。兩者并無本質區別，只是源碼文件存儲的字符不同而已，但，縮進可視化插件對兩類縮進顯示方式不同，前者只能顯示為粗塊，后者可顯示為細條，就我的審美觀而言，選后者。增加如下配置信息：

" 自適應不同語言的智能縮進 filetype indent on " 將制表符擴展為空格 set expandtab " 設置編輯時制表符占用空格數 set tabstop=4 " 設置格式化時制表符占用空格數 set shiftwidth=4 " 讓 vim 把連續數量的空格視為一個制表符 set softtabstop=4

其中，注意下 expandtab、tabstop 與 shiftwidth、softtabstop、retab：

• expandtab，把制表符轉換為多個空格，具體空格數量參考 tabstop 和 shiftwidth 變量；
• tabstop 與 shiftwidth 是有區別的。tabstop 指定我們在插入模式下輸入一個制表符占據的空格數量，linux 內核編碼規范建議是 8，看個人需要；shiftwidth 指定在進行縮進格式化源碼時制表符占據的空格數。所謂縮進格式化，指的是通過 vim 命令由 vim 自動對源碼進行縮進處理，比如其他人的代碼不滿足你的縮進要求，你就可以對其進行縮進格式化。縮進格式化，需要先選中指定行，要么鍵入 = 讓 vim 對該行進行智能縮進格式化，要么按需鍵入多次 < 或 > 手工縮進格式化；
• softtabstop，如何處理連續多個空格。因為 expandtab 已經把制表符轉換為空格，當你要刪除制表符時你得連續刪除多個空格，該設置就是告訴 vim 把連續數量的空格視為一個制表符，即，只刪一個字符即可。通常應將這tabstop、shiftwidth、softtabstop 三個變量設置為相同值；

另外，你總會閱讀其他人的代碼吧，他們對制表符定義規則與你不同，這時你可以手工執行 vim 的 retab 命令，讓 vim 按上述規則重新處理制表符與空格關系。

很多編碼規范建議縮進（代碼嵌套類似）最多不能超過 4 層，但難免有更多層的情況，縮進一多，我那個暈啊：

（多層縮進）

我希望有種可視化的方式能將相同縮進的代碼關聯起來，Indent Guides（https://github.com/nathanaelkane/vim-indent-guides）來了。安裝好該插件后，增加如下配置信息：

" 隨 vim 自啟動 let g:indent_guides_enable_on_vim_startup=1 " 從第二層開始可視化顯示縮進 let g:indent_guides_start_level=2 " 色塊寬度 let g:indent_guides_guide_size=1 " 快捷鍵 i 開/關縮進可視化 :nmap <silent> <Leader>i <Plug>IndentGuidesToggle

重啟 vim 效果如下：

（不連續的縮進可視化）

斷節？Indent Guides 通過識別制表符來繪制縮進連接線，斷節處是空行，沒有制表符，自然繪制不出來，算是個小 bug，但瑕不掩瑜，有個小技巧可以解決，換行-空格-退格：

（完美可視化縮進）

4.3 代碼折疊

有時為了去除干擾，集中精力在某部分代碼片段上，我會把不關注部分代碼折疊起來。vim 自身支持多種折疊：手動建立折疊（manual）、基于縮進進行折疊（indent）、基于語法進行折疊（syntax）、未更改文本構成折疊（diff）等等，其中，indent、syntax 比較適合編程，按需選用。增加如下配置信息：

" 基于縮進或語法進行代碼折疊 "set foldmethod=indent set foldmethod=syntax " 啟動 vim 時關閉折疊代碼 set nofoldenable

操作：za，打開或關閉當前折疊；zM，關閉所有折疊；zR，打開所有折疊。效果如下：

（代碼折疊）

4.4 接口與實現快速切換

我習慣把類的接口和實現分在不同文件中，常有在接口文件（MyClass.h）和實現文件（MyClass.cpp）中來回切換的操作。你當然可以先分別打開接口文件和實現文件，再手動切換，但效率不高。我希望，假如在接口文件中，vim 自動幫我找到對應的實現文件，當鍵入快捷鍵，在新 buffer 中打開對應實現文件。

vim-fswitch（https://github.com/derekwyatt/vim-fswitch?）來了。安裝后增加配置信息：

" *.cpp 和 *.h 間切換 nmap <silent> <Leader>sw :FSHere<cr>

這樣，鍵入 ;sw 就能在實現文件和接口文件間切換。如下圖所示：

（接口文件與實現文件切換）

上圖中，初始狀態先打開了接口文件 MyClass.h，鍵入 ;sw 后，vim 在新 buffer 中打開實現文件 MyClass.cpp，并在當前窗口中顯示；再次鍵入 ;sw 后，當前窗口切回接口文件。

4.5 代碼收藏

源碼分析過程中，常常需要在不同代碼間來回跳轉，我需要“收藏”分散在不同處的代碼行，以便需要查看時能快速跳轉過去，這時，vim 的書簽（mark）功能派上大用途了。

vim 書簽的使用很簡單，在你需要收藏的代碼行鍵入 mm，這樣就收藏好了，你試試，沒反應？不會吧，難道你 linux 內核編譯參數有問題，或者，vim 的編譯參數沒給全，讓我想想，別急，喔，對了，你是指看不到書簽？好吧，我承認這是 vim 最大的坑，書簽所在行與普通行外觀上沒任何差別，肉眼，你是找不到他滴。這可不行，得來個讓書簽可視化的插件，vim-signature（https://github.com/kshenoy/vim-signature?）。vim-signature 通過在書簽所在行的前面添加字符的形式，以此可視化書簽，這就要求你源碼安裝的 vim 具備 signs 特性，具體可在 vim 命令模式下鍵入

:echo has('signs')

若顯示 1 則具備該特性，反之 0 則不具備該特性，需參考“1 源碼安裝編輯器 vim ”重新編譯 vim。

vim 的書簽分為兩類，獨立書簽和分類書簽。獨立書簽，書簽名只能由字母（a-zA-Z）組成，長度最多不超過 2 個字母，并且，同個文件中，不同獨立書簽名中不能含有相同字母，比如，a 和 bD 可以同時出現在同個文件在，而 Fc 和 c 則不行。分類書簽，書簽名只能由可打印特殊字符（!@#$%^&*()）組成，長度只能有 1 個字符，同個文件中，你可以把不同行設置成同名書簽，這樣，這些行在邏輯上就歸類成相同類型的書簽了。下圖定義了名為 a 和 dF 兩個獨立書簽（分別 259 行和 261 行）、名為 # 的一類分類書簽（含 256 行和 264 行）、名為 @ 的一類分類書簽（257 行），如下所示：

（獨立書簽和分類書簽）

兩種形式的書簽完全分布在各自不同的空間中，所以，它倆的任何操作都是互不相同的，比如，你無法遍歷所有書簽，要么只能在各個獨立書簽間遍歷，要么只能在分類書簽間遍歷。顯然，兩種形式的書簽都有各自的使用場景，就我而言，只使用獨立書簽，原因有二：一是獨立書簽可保存，當我設置好獨立書簽后關閉文檔，下次重新打開該文檔時，先前的獨立書簽仍然有效，而分類書簽沒有該特性（其他文檔環境恢復參見“6.3 環境恢復”）；一是減少記憶快捷鍵，光是獨立書簽就有 8 種遍歷方式，每種遍歷對應一種快捷鍵，太難記了。

vim-signature 快捷鍵如下：

let g:SignatureMap = {\ 'Leader' : "m",\ 'PlaceNextMark' : "m,",\ 'ToggleMarkAtLine' : "m.",\ 'PurgeMarksAtLine' : "m-",\ 'DeleteMark' : "dm",\ 'PurgeMarks' : "mda",\ 'PurgeMarkers' : "m<BS>",\ 'GotoNextLineAlpha' : "']",\ 'GotoPrevLineAlpha' : "'[",\ 'GotoNextSpotAlpha' : "`]",\ 'GotoPrevSpotAlpha' : "`[",\ 'GotoNextLineByPos' : "]'",\ 'GotoPrevLineByPos' : "['",\ 'GotoNextSpotByPos' : "mn",\ 'GotoPrevSpotByPos' : "mp",\ 'GotoNextMarker' : "[+",\ 'GotoPrevMarker' : "[-",\ 'GotoNextMarkerAny' : "]=",\ 'GotoPrevMarkerAny' : "[=",\ 'ListLocalMarks' : "ms",\ 'ListLocalMarkers' : "m?"\ }

夠多了吧，粗體部分是按個人習慣重新定義的快捷鍵，請添加進 .vimrc 中。

常用的操作也就如下幾類：

• 書簽設定。mx，設定/取消當前行名為 x 的標簽；m,，自動設定下一個可用書簽名，前面提說，獨立書簽名是不能重復的，在你已經有了多個獨立書簽，當想再設置書簽時，需要記住已經設定的所有書簽名，否則很可能會將已有的書簽沖掉，這可不好，所以，vim-signature 為你提供了 m, 快捷鍵，自動幫你選定下一個可用獨立書簽名；mda，刪除當前文件中所有獨立書簽。
• 書簽羅列。m?，羅列出當前文件中所有書簽，選中后回車可直接跳轉；
• 書簽跳轉。mn，按行號前后順序，跳轉至下個獨立書簽；mp，按行號前后順序，跳轉至前個獨立書簽。書簽跳轉方式很多，除了這里說的行號前后順序，還可以基于書簽名字母順序跳轉、分類書簽同類跳轉、分類書簽不同類間跳轉等等。

效果如下：

（可視化書簽）

我雖然選用了 vim-signature，但不代表它完美了，對我而言，無法在不同文件的書簽間跳轉絕對算是硬傷。另外，如果覺得收藏的代碼行只有行首符號來表示不夠醒目，你可以考慮 BOOKMARKS--Mark-and-Highlight-Full-Lines 這個插件（https://github.com/vim-scripts/BOOKMARKS--Mark-and-Highlight-Full-Lines?），它可以讓書簽行高亮，如下是它的快捷鍵：，高亮所有書簽行；，關閉所有書簽行高亮；，清除 [a-z] 的所有書簽；，收藏當前行；，取消收藏當前行。

4.6 標識符列表

本節之前的內容，雖說與代碼開發有些關系，但最多也只能算作用戶體驗層面的，真正提升生產效率的內容將從此開始。

本文主題是探討如何將 vim 打造成高效的 C/C++ 開發環境，希望實現標識符列表、定義跳轉、聲明提示、實時診斷、代碼補全等等系列功能，這些都需要 vim 能夠很好地理解我們的代碼（不論是 vim 自身還是借助插件甚至第三方工具），如何幫助 vim 理解代碼？基本上，有兩種主流方式：標簽系統和語義系統。至于優劣，簡單來說，標簽系統配置簡單，而語義系統效果精準，后者是趨勢。目前對于高階 IDE 功能，部分已經有對應基于語義的插件支撐，而部分仍只能通過基于標簽的方式實現，若同個功能既有語義插件又有標簽插件，優選語義。

標簽系統

代碼中的類、結構、類成員、函數、對象、宏等等這些統稱為標識符，每個標識符的定義、所在文件中的行位置、所在文件的路徑等等信息就是標簽（tag）。

Exuberant Ctags（http://ctags.sourceforge.net/?，后簡稱 ctags）就是一款經典的用于生成代碼標簽信息的工具 。ctags 最初只支持生成 C/C++ 語言，目前已支持 41 種語言，具體列表運行如下命令獲取：

ctags --list-languages

學習知識最好方式就是動手實踐。我們以 main.cpp、my_class.h、my_class.cpp 三個文件為例：

第一步，準備代碼文件。創建演示目錄 /data/workplace/example/、庫子目錄 /data/workplace/example/lib/，創建如下內容的 main.cpp：

#include <iostring> #include <string> #include "lib/my_class.h" using namespace std; int g_num = 128; // 重載函數 static void printMsg (char ch) { std::cout << ch << std::endl; } int main (void) { // 局部對象const string name = "yangyang.gnu"; // 類 MyClass one; // 成員函數 one.printMsg(); // 使用局部對象 cout << g_num << name << endl; return (EXIT_SUCCESS); }

創建如下內容的 my_class.h：

#pragma once class MyClass { public: void printMsg(void); private: ; };

創建如下內容的 my_class.cpp：

#include "my_class.h" // 重載函數 static void printMsg (int i) { std::cout << i << std::endl; } void MyClass::printMsg (void) { std::cout << "I'M MyClass!" << std::endl; }

第二步，生成標簽文件。現在運行 ctags 生成標簽文件：

cd /data/workplace/example/ ctags -R --c++-kinds=+p+l+x+c+d+e+f+g+m+n+s+t+u+v --fields=+liaS --extra=+q --language-force=c++

命令行參數較多，主要關注 --c++-kinds，ctags 默認并不會提取所有標簽，運行

ctags --list-kinds=c++

可看到 ctags 支持生成標簽類型的全量列表：

c classes d macro definitions e enumerators (values inside an enumeration) f function definitions g enumeration names l local variables [off] m class, struct, and union members n namespaces p function prototypes [off] s structure names t typedefs u union names v variable definitions x external and forward variable declarations [off]

其中，標為 off 的局部對象、函數聲明、外部對象等類型默認不會生成標簽，所以我顯式加上所有類型。運行完后，example/ 下多了個文件 tags，內容大致如下：

!_TAG_FILE_FORMAT 2 /extended format; --format=1 will not append ;" to lines/ !_TAG_FILE_SORTED 1 /0=unsorted, 1=sorted, 2=foldcase/ !_TAG_PROGRAM_AUTHOR Darren Hiebert /dhiebert@users.sourceforge.net/ !_TAG_PROGRAM_NAME Exuberant Ctags // !_TAG_PROGRAM_URL http://ctags.sourceforge.net /official site/ !_TAG_PROGRAM_VERSION 5.8 // MyClass lib/my_class.h /^class MyClass $/;" c MyClass::printMsg lib/my_class.cpp /^MyClass::printMsg (void) $/;" f class:MyClass signature:(void) MyClass::printMsg lib/my_class.h /^ void printMsg(void);$/;" p class:MyClass access:public signature:(void) endl lib/my_class.cpp /^ std::cout << "I'M MyClass!" << std::endl;$/;" m class:std file: endl lib/my_class.cpp /^ std::cout << i << std::endl;$/;" m class:std file: endl main.cpp /^ cout << g_num << name << endl;$/;" l endl main.cpp /^ std::cout << ch << std::endl;$/;" m class:std file: g_num main.cpp /^int g_num = 128;$/;" v main main.cpp /^main (void) $/;" f signature:(void) name main.cpp /^ const string name = "yangyang.gnu";$/;" l one main.cpp /^ MyClass one;$/;" l printMsg lib/my_class.cpp /^MyClass::printMsg (void) $/;" f class:MyClass signature:(void) printMsg lib/my_class.cpp /^printMsg (int i) $/;" f file: signature:(int i) printMsg lib/my_class.h /^ void printMsg(void);$/;" p class:MyClass access:public signature:(void) printMsg main.cpp /^ one.printMsg();$/;" p file: signature:() printMsg main.cpp /^printMsg (char ch) $/;" f file: signature:(char ch) std::endl lib/my_class.cpp /^ std::cout << "I'M MyClass!" << std::endl;$/;" m class:std file: std::endl lib/my_class.cpp /^ std::cout << i << std::endl;$/;" m class:std file: std::endl main.cpp /^ std::cout << ch << std::endl;$/;" m class:std file:

其中，! 開頭的幾行是 ctags 生成的軟件信息忽略之，下面的就是我們需要的標簽，每個標簽項至少有如下字段（命令行參數不同標簽項的字段數不同）：標識符名、標識符所在的文件名（也是該文件的相對路徑）、標識符所在行的內容、標識符類型（如，l 表示局部對象），另外，若是函數，則有函數簽名字段，若是成員函數，則有訪問屬型字段等等。

語義系統

通過 ctags 這類標簽系統在一定程度上助力 vim 理解我們的代碼，對于 C 語言這類簡單語言來說，差不多也夠了。近幾年，隨著 C++11/14 的推出，諸如類型推導、lamda 表達式、模版等等新特性，標簽系統顯得有心無力，這個星球最了解代碼的工具非編譯器莫屬，如果編譯器能在語義這個高度幫助 vim 理解代碼，那么我們需要的各項 IDE 功能肯定能達到另一個高度。

語義系統，編譯器必不可少。GCC 和 clang 兩大主流 C/C++ 編譯器，作為語義系統的支撐工具，我選擇后者，除了 clang 對新標準支持及時、錯誤診斷信息清晰這些優點之外，更重要的是，它在高內聚、低耦合方面做得非常好，各類插件可以調用 libclang 獲取非常完整的代碼分析結果，從而輕松且優雅地實現高階 IDE 功能。你對語義系統肯定還是比較懵懂，緊接著的“基于語義的聲明/定義跳轉”會讓你有更為直觀的了解，現在，請跳轉至“7.1 編譯器/構建工具集成”，一是了解 clang 相較 GCC 的優勢，二是安裝好最新版 clang 及其標準庫，之后再回來。

基于標簽的標識符列表

在閱讀代碼時，經常分析指定函數實現細節，我希望有個插件能把從當前代碼文件中提取出的所有標識符放在一個側邊子窗口中，并且能能按語法規則將標識符進行歸類，tagbar （https://github.com/majutsushi/tagbar?）是一款基于標簽的標識符列表插件，它自動周期性調用 ctags 獲取標簽信息（僅保留在內存，不落地成文件）。安裝完 tagbar 后，在 .vimrc 中增加如下信息：

" 設置 tagbar 子窗口的位置出現在主編輯區的左邊 let tagbar_left=1 " 設置顯示／隱藏標簽列表子窗口的快捷鍵。速記：identifier list by tag nnoremap <Leader>ilt :TagbarToggle<CR> " 設置標簽子窗口的寬度 let tagbar_width=32 " tagbar 子窗口中不顯示冗余幫助信息 let g:tagbar_compact=1 " 設置 ctags 對哪些代碼標識符生成標簽 let g:tagbar_type_cpp = {\ 'kinds' : [\ 'c:classes:0:1',\ 'd:macros:0:1',\ 'e:enumerators:0:0', \ 'f:functions:0:1',\ 'g:enumeration:0:1',\ 'l:local:0:1',\ 'm:members:0:1',\ 'n:namespaces:0:1',\ 'p:functions_prototypes:0:1',\ 's:structs:0:1',\ 't:typedefs:0:1',\ 'u:unions:0:1',\ 'v:global:0:1',\ 'x:external:0:1'\ ],\ 'sro' : '::',\ 'kind2scope' : {\ 'g' : 'enum',\ 'n' : 'namespace',\ 'c' : 'class',\ 's' : 'struct',\ 'u' : 'union'\ },\ 'scope2kind' : {\ 'enum' : 'g',\ 'namespace' : 'n',\ 'class' : 'c',\ 'struct' : 's',\ 'union' : 'u'\ } \ }

前面提過，ctags 默認并不會提取局部對象、函數聲明、外部對象等類型的標簽，我必須讓 tagbar 告訴 ctags 改變默認參數，這是 tagbar_type_cpp 變量存在的主要目的，所以前面的配置信息中將局部對象、函數聲明、外部對象等顯式將其加進該變量的 kinds 域中。具體格式為

{short}:{long}[:{fold}[:{stl}]]

用于描述函數、變量、結構體等等不同類型的標識符，每種類型對應一行。其中，short 將作為 ctags 的 --c++-kinds 命令行選項的參數，類似：

--c++-kinds=+p+l+x+c+d+e+f+g+m+n+s+t+u+v

long 將作為 short 的簡要描述展示在 vim 的 tagbar 子窗口中；fold 表示這種類型的標識符是否折疊顯示；stl 指定是否在 vim 狀態欄中顯示附加信息。

重啟 vim 后，打開一個 C/C++ 源碼文件，鍵入 ilt，將在左側的 tagbar 窗口中將可看到標簽列表：

（基于標簽的標識符列表）

從上圖可知 tagbar 的幾個特點：

• 按作用域歸類不同標簽。按名字空間 n_foo、類 Foo 進行歸類，在內部有聲明、有定義；
• 顯示標簽類型。名字空間、類、函數等等；
• 顯示完整函數原型；
• 圖形化顯示共有成員（+）、私有成員（-）、保護成員（#）；

在標識符列表中選中對應標識符后回車即可跳至源碼中對應位置；在源碼中停頓幾秒，tagbar 將高亮對應標識符；每次保存文件時或者切換到不同代碼文件時 tagbar 自動調用 ctags 更是標簽數據庫；tagbar 有兩種排序方式，一是按標簽名字母先后順序、一是按標簽在源碼中出現的先后順序，在 .vimrc 中我配置選用后者，鍵入 s 切換不同不同排序方式。

4.7 聲明/定義跳轉

假設你正在分析某個開源項目源碼，在 main.cpp 中遇到調用函數 func()，想要查看它如何實現，一種方式：在 main.cpp 中查找 -> 若沒有在工程內查找 -> 找到后打開對應文件 -> 文件內查找其所在行 -> 移動光標到該行 -> 分析完后切換會先前文件，不僅效率太低更要命的是影響我的思維連續性。我需要另外高效的方式，就像真正函數調用一樣：光標選中調用處的 func() -> 鍵入某個快捷鍵自動轉換到 func() 實現處 -> 鍵入某個鍵又回到 func() 調用處，這就是所謂的定義跳轉。

基本上，vim 世界存在兩類導航：基于標簽的跳轉和基于語義的跳轉。

基于標簽的聲明/定義跳轉

繼續延用前面接收標簽系統的例子文件 main.cpp、my_class.h、my_class.cpp，第二步已經生成好了標簽文件，那么要實現聲明/定義跳轉，需要第三步，引入標簽文件。這讓 vim 知曉標簽文件的路徑。在 /data/workplace/example/ 目錄下用 vim 打開 main.cpp，在 vim 中執行如下目錄引入標簽文件 tags：

:set tags+=/data/workplace/example/tags

既然 vim 有個專門的命令來引入標簽，說明 vim 能識別標簽。雖然標簽文件中并無行號，但已經有標簽所在文件，以及標簽所在行的完整內容，vim 只需切換至對應文件，再在文件內作內容查找即可找到對應行。換言之，只要有對應的標簽文件，vim 就能根據標簽跳轉至標簽定義處。

這時，你可以體驗下初級的聲明/定義跳轉功能。把光標移到 main.cpp 的 one.printMsg() 那行的 printMsg 上，鍵入快捷鍵 g]，vim 將羅列出名為 printMsg 的所有標簽候選列表，按需選擇鍵入編號即可跳轉進入。如下圖：

（待選標簽）

目前為止，離我預期還有差距。

第一，選擇候選列表影響思維連續性。首先得明白為何會出現待選列表。前面說過，vim 做的事情很簡單，就是把光標所在單詞放到標簽文件中查找，如果只有一個，當然你可以直接跳轉過去，大部分時候會找到多項匹配標簽，比如，函數聲明、函數定義、函數調用、函數重載等等都會導致同個函數名出現在多個標簽中，vim 無法知道你要查看哪項，只能讓你自己選擇。其實，因為標簽文件中已經包含了函數簽名屬性，vim 的查找機制如果不是基于關鍵字，而是基于語義的話，那也可以直接命中，期待后續 vim 有此功能吧。既然無法直接解決，換個思路，我不想選擇列表，但可以接受遍歷匹配標簽。就是說，我不想輸入數字選擇第幾項，但可以接受鍵入正向快捷鍵后遍歷第一個匹配標簽，再次鍵入快捷鍵遍歷第二個，直到最后一個，鍵入反向快捷鍵逆序遍歷。這下事情簡單了，命令 :tnext 和 :tprevious 分別先后和向前遍歷匹配標簽，定義兩個快捷鍵搞定：

" 正向遍歷同名標簽 nmap <Leader>tn :tnext<CR> " 反向遍歷同名標簽 nmap <Leader>tp :tprevious<CR>

等等，這還不行，vim 中有個叫標簽棧（tags stack）的機制，:tnext、:tprevious 只能遍歷已經壓入標簽棧內的標簽，所以，你在遍歷前需要通過快捷鍵 ctrl-] 將光標所在單詞匹配的所有標簽壓入標簽棧中，然后才能遍歷。不說復雜了，以后你只需先鍵入 ctrl-]，若沒跳轉至需要的標簽，再鍵入 tn 往后或者 tp 往前遍歷即可。如下圖所示：

（基于標簽的跳轉）

第二，如何返回先前位置。當分析完函數實現后，我需要返回先前調用處，可以鍵入 vim 快捷鍵 ctrl-t 返回，如果想再次進入，可以用前面介紹的方式，或者鍵入 ctrl-i。另外，注意，ctrl-o 以是一種返回快捷鍵，但與 ctrl-t 的返回不同，前者是返回上次光標停留行、后者返回上個標簽。

第三，如何自動生成標簽并引入。開發時代碼不停在變更，每次還要手動執行 ctags 命令生成新的標簽文件，太麻煩了，得想個法周期性針對這個工程自動生成標簽文件，并通知 vim 引人該標簽文件，嘿，還真有這樣的插件 —— indexer（https://github.com/vim-scripts/indexer.tar.gz?）。indexer 依賴 DfrankUtil（https://github.com/vim-scripts/DfrankUtil）、vimprj（https://github.com/vim-scripts/vimprj?）兩個插件，請一并安裝。請在 .vimrc 中增加：

" 設置插件 indexer 調用 ctags 的參數 " 默認 --c++-kinds=+p+l，重新設置為 --c++-kinds=+p+l+x+c+d+e+f+g+m+n+s+t+u+v " 默認 --fields=+iaS 不滿足 YCM 要求，需改為 --fields=+iaSl let g:indexer_ctagsCommandLineOptions="--c++-kinds=+p+l+x+c+d+e+f+g+m+n+s+t+u+v --fields=+iaSl --extra=+q"

另外，indexer 還有個自己的配置文件，用于設定各個工程的根目錄路徑，配置文件位于 ~/.indexer_files，內容可以設定為：

--------------- ~/.indexer_files --------------- [foo] /data/workplace/foo/src/ [bar] /data/workplace/bar/src/

上例設定了兩個工程的根目錄，方括號內是對應工程名，路徑為工程的代碼目錄，不要包含構建目錄、文檔目錄，以避免將產生非代碼文件的標簽信息。這樣，從以上目錄打開任何代碼文件時，indexer 便對整個目錄創建標簽文件，若代碼文件有更新，那么在文件保存時，indexer 將自動調用 ctags 更新標簽文件，indexer 生成的標簽文件以工程名命名，位于 ~/.indexer_files_tags/，并自動引入進 vim 中，那么

:set tags+=/data/workplace/example/tags

一步也省了。好了，解決了這三個問題后，vim 的代碼導航基本已經達到我的預期。

基于語義的聲明/定義跳轉

有個 vim 插件叫 YCM，有個 C++ 編譯器叫 clang，只要正確使用它倆，你將獲得無與倫比的代碼導航用戶體驗，以及，代碼補全。當然，代價是相對復雜的配置，涉及幾個后續章節知識點（“基于語義的智能補全”和“編譯器/構建工具集成”），正因如此，此時我只給出快捷鍵設置，在看完“基于語義的智能補全”后請返回此處，重新查閱。

請增加如下快捷鍵到 .vimrc 中：

nnoremap <leader>jc :YcmCompleter GoToDeclaration<CR> " 只能是 #include 或已打開的文件 nnoremap <leader>jd :YcmCompleter GoToDefinition<CR>

效果如下：

（基于語義的跳轉）

另外，基于標簽的調整建議你也要了解，有助于你熟悉標簽系統，畢竟，使用標簽的插件很有幾個。

4.8 內容查找

vim 支持正則表達式，那么已經具有強勁的查供能力，在當前文件內查找，vim 的 / 和 ? 查找命令非常好用，但工程內查找，自帶的查找用戶體驗還無法達到我的預期。

內容查找，你第一反應會想到 grep 和 ack 兩個工具，沒錯，它倆強大的正則處理能力無需質疑，如果有插件能在 vim 中集成兩個工具之一，那么任何查找任務均可輕松搞定，為此，出現了 grep.vim（https://github.com/yegappan/grep?）和 ack.vim（https://github.com/mileszs/ack.vim?）兩個插件，通過它們，你可以在 vim 中自在地使用高度整合的 grep 或 ack 兩個外部命令，就像 vim 的內部命令一樣：查找時，把光標定位到待查找關鍵字上后，通過快捷鍵立即查找該關鍵字，查詢結果通過列表形式將關鍵字所在行羅列出來，選擇后就能跳轉到對應位置。很好，這全部都是我想要的，但是，不是我想要的全部。

你知道，在分析源碼時，同個關鍵字會在不同文件的不同位置多次出現，grep.vim 和 ack.vim 只能“將關鍵字所在行羅列出來”，如果關鍵字出現的那幾行完全相同，那么，我單憑這個列表是無法確定哪行是我需要的，比如，我查找關鍵字 cnt，代碼中，cnt 在 4 行出現過、64 行、128 行、1024 行都出現過，且每行內容均為

++cnt;

這時，即便 grep.vim 或 ack.vim 在一個有四個選項的列表中為你羅列出相關行，因為完全相同，所以你也無法確定到底應該查看第幾項。換言之，除了羅列關鍵字所在行之外，我還需要看到所在行的上下幾行，這樣，有了上下文，我就可以最終決定哪一行是我需要的了。ctrlsf.vim（https://github.com/dyng/ctrlsf.vim?）為此而生。

ctrlsf.vim 后端調用 ack，所以你得提前自行安裝，版本不得低于 v2.0，openSUSE 用戶可以

zypper --no-refresh in ack

進行安裝。ctrlsf.vim 支持 ack 所有選項，要查找某個關鍵字（如，yangyang），你可以想讓光標定位在該關鍵字上面，然后命令模式下鍵入

:CtrlSF

將自動提取光標所在關鍵字進行查找，你也可以指定 ack 的選項

:CtrlSF -i -C 1 [pattern] /my/path/

為方便操作，我設定了快捷鍵：

" 使用 ctrlsf.vim 插件在工程內全局查找光標所在關鍵字，設置快捷鍵。快捷鍵速記法：search in project nnoremap <Leader>sp :CtrlSF<CR>

避免手工鍵入命令的麻煩。查找結果將以子窗口在左側呈現，不僅羅列出所有匹配項，而且給出匹配項的上下文。如果從上下文中你還覺得信息量不夠，沒事，可以鍵入 p 鍵，將在右側子窗口中給出該匹配項的完整代碼，而不再僅有前后幾行。不想跳至任何匹配項，可以直接鍵入 q 退出 ctrlsf.vim；如果有鐘意的匹配項，光標定位該項后回車，立即跳至新 buffer 中對應位置。

太性感了，以關鍵字 CmdlineOption 為例，如下所示：

（內容查找）

4.9 內容替換

有個名為 iFoo 的全局變量，被工程中 16 個文件引用過，由于你岳母覺得匈牙利命名法嚴重、異常、絕對以及十分萬惡，為討岳母歡心，不得不將該變量更名為 foo，怎么辦？依次打開每個文件，逐一查找后替換？對我而言，內容替換存在兩種場景：快捷替換和精確替換。

快捷替換

前面介紹的 ctrlsf 已經把匹配的字符串匯總在側邊子窗口中顯示了，同時，它還允許我們直接在該子窗口中進行編輯操作，在這種環境下，如果我們能快捷選中所有匹配字符串，那么就可以先批量刪除再在原位插入新的字符串，這豈不是我們需要的替換功能么？

快捷選中 ctrlsf 子窗口中的多個匹配項，關鍵還是這些匹配項分散在不同行的不同位置，這就需要多光標編輯功能，vim-multiple-cursors 插件（https://github.com/terryma/vim-multiple-cursors?）為次而生。裝好 vim-multiple-cursors 后，你隨便編輯個文檔，隨便輸入多個相同的字符串，先在可視化模式下選中其中一個，接著鍵入 ctrl-n，你會發現第二個該字符串也被選中了，持續鍵入 ctrl-n，你可以選中所有相同的字符串，把這個功能與 ctrlsf 結合，你來感受下：

（快捷替換）

上圖中，我想將 prtHelpInfo() 更名為 showHelpInfo()，先通過 ctrlsf 找到工程中所有 prtHelpInfo，然后直接在 ctrlsf 子窗口中選中第一個 ptr，再通過 vim-multiple-cursors 選中第二個 ptr，接著統一刪除 ptr 并統一鍵入 show，最后保存并重新加載替換后的文件。

vim-multiple-cursors 默認快捷鍵與我系統中其他軟件的快捷鍵沖突，按各自習慣重新設置：

let g:multi_cursor_next_key='<S-n>' let g:multi_cursor_skip_key='<S-k>'

精確替換

vim 有強大的內容替換命令：

:[range]s/{pattern}/{string}/[flags]

在進行內容替換操作時，我關注幾個因素：如何指定替換文件范圍、是否整詞匹配、是否逐一確認后再替換。

如何指定替換文件范圍？

• 如果在當前文件內替換，[range] 不用指定，默認就在當前文件內；
• 如果在當前選中區域，[range] 也不用指定，在你鍵入替換命令時，vim 自動將生成如下命令：

:'<,'>s/{pattern}/{string}/[flags]

• 你也可以指定行范圍，如，第三行到第五行：

:3,5s/{pattern}/{string}/[flags]

• 如果對打開文件進行替換，你需要先通過 :bufdo 命令顯式告知 vim 范圍，再執行替換；
• 如果對工程內所有文件進行替換，先 :args **/.cpp */*.h 告知 vim 范圍，再執行替換；

是否整詞匹配？{pattern} 用于指定匹配模式。如果需要整詞匹配，則該字段應由 < 和 > 修飾待替換字符串（如，<iFoo>）；無須整詞匹配則不用修飾，直接給定該字符串即可；

是否逐一確認后再替換？[flags] 可用于指定是否需要確認。若無須確認，該字段設定為 ge 即可；有時不見得所有匹配的字符串都需替換，若在每次替換前進行確認，該字段設定為 gec 即可。

是否整詞匹配和是否確認兩個條件疊加就有 4 種組合：非整詞且不確認、非整詞且確認、整詞且不確認、整詞且確認，每次手工輸入這些命令真是麻煩；我把這些組合封裝到一個函數中，如下 Replace() 所示：

" 替換函數。參數說明： " confirm：是否替換前逐一確認 " wholeword：是否整詞匹配 " replace：被替換字符串 function! Replace(confirm, wholeword, replace)walet flag = ''if a:confirmlet flag .= 'gec'elselet flag .= 'ge'endiflet search = ''if a:wholewordlet search .= '\<' . escape(expand('<cword>'), '/\.*$^~[') . '\>'elselet search .= expand('<cword>')endiflet replace = escape(a:replace, '/\&~')execute 'argdo %s/' . search . '/' . replace . '/' . flag . '| update' endfunction

為最大程度減少手工輸入，Replace() 還能自動提取待替換字符串（只要把光標移至待替換字符串上），同時，替換完成后自動為你保存更改的文件。現在要做的就是賦予 confirm、wholeword 不同實參實現 4 種組合，再綁定 4 個快捷鍵即可。如下：

" 不確認、非整詞 nnoremap <Leader>R :call Replace(0, 0, input('Replace '.expand('<cword>').' with: '))<CR> " 不確認、整詞 nnoremap <Leader>rw :call Replace(0, 1, input('Replace '.expand('<cword>').' with: '))<CR> " 確認、非整詞 nnoremap <Leader>rc :call Replace(1, 0, input('Replace '.expand('<cword>').' with: '))<CR> " 確認、整詞 nnoremap <Leader>rcw :call Replace(1, 1, input('Replace '.expand('<cword>').' with: '))<CR> nnoremap <Leader>rwc :call Replace(1, 1, input('Replace '.expand('<cword>').' with: '))<CR>

我平時用的最多的無須確認但整詞匹配的替換模式，即 <leader>rw。

請將完整配置信息添加進 .vimrc 中：

" 替換函數。參數說明： " confirm：是否替換前逐一確認 " wholeword：是否整詞匹配 " replace：被替換字符串 function! Replace(confirm, wholeword, replace)walet flag = ''if a:confirmlet flag .= 'gec'elselet flag .= 'ge'endiflet search = ''if a:wholewordlet search .= '\<' . escape(expand('<cword>'), '/\.*$^~[') . '\>'elselet search .= expand('<cword>')endiflet replace = escape(a:replace, '/\&~')execute 'argdo %s/' . search . '/' . replace . '/' . flag . '| update' endfunction " 不確認、非整詞 nnoremap <Leader>R :call Replace(0, 0, input('Replace '.expand('<cword>').' with: '))<CR> " 不確認、整詞 nnoremap <Leader>rw :call Replace(0, 1, input('Replace '.expand('<cword>').' with: '))<CR> " 確認、非整詞 nnoremap <Leader>rc :call Replace(1, 0, input('Replace '.expand('<cword>').' with: '))<CR> " 確認、整詞 nnoremap <Leader>rcw :call Replace(1, 1, input('Replace '.expand('<cword>').' with: '))<CR> nnoremap <Leader>rwc :call Replace(1, 1, input('Replace '.expand('<cword>').' with: '))<CR>

比如，我將工程的所有 *.cpp 和 *.h 中的關鍵字 MyClassA 按不確認且整詞匹配模式替換成 MyClass，所以注釋中的關鍵字不會被替換掉。如下所示：

（不確認且整詞匹配模式的替換）

又比如，對當前文件采用需確認且無須整詞匹配的模式進行替換，你會看到注釋中的關鍵字也被替換了：

（確認且無須整詞匹配模式的替換）

5 代碼開發

在具體編碼過程中，我需要一系列提高生產力的功能：批量開/關注釋、快速輸入代碼模板、代碼智能補全、路徑智能補全、從接口生成實現、查看參考庫信息等等，我們逐一來實現。

5.1 快速開關注釋

需要注釋時，到每行代碼前輸入 //，取消注釋時再刪除 //，這種方式不是現代人的行為。IDE 應該支持對選中文本塊批量（每行）添加注釋符號，反之，可批量取消。本來 vim 通過宏方式可以支持該功能，但每次注釋時要自己錄制宏，關閉 vim 后宏無法保存，所以有人專門編寫了一款插件 NERD Commenter（https://github.com/scrooloose/nerdcommenter?），NERD Commenter 根據編輯文檔的擴展名自適應采用何種注釋風格，如，文檔名 x.cpp 則采用 // 注釋風格，而 x.c 則是 /**/ 注釋風格；另外，如果選中的代碼并非整行，那么該插件將用 /**/ 只注釋選中部分。

常用操作：

• <leader>cc，注釋當前選中文本，如果選中的是整行則在每行首添加 //，如果選中一行的部分內容則在選中部分前后添加分別 /、/；
• <leader>cu，取消選中文本塊的注釋。

如下圖所示：

（快速開/關注釋）

另外，有時需要 ASCII art 風格的注釋，可用 DrawIt!（https://github.com/vim-scripts/DrawIt?），它可以讓你用方向鍵快速繪制出。

常用操作就兩個，:Distart，開始繪制，可用方向鍵繪制線條，空格鍵繪制或擦除字符；:Distop，停止繪制。

如下圖所示：

（ASCII art 風格注釋）

5.2 模板補全

開發時，我經常要輸入相同的代碼片斷，比如 if-else、switch 語句，如果每個字符全由手工鍵入，我可吃不了這個苦，我想要簡單的鍵入就能自動幫我完成代碼模板的輸入，并且光標停留在需要我編輯的位置，比如鍵入 if，vim 自動完成

if (/* condition */) {TODO }

而且幫我選中 /* condition */ 部分，不會影響編碼連續性 —— UltiSnips（https://github.com/SirVer/ultisnips?），我的選擇。

在進行模板補全時，你是先鍵入模板名（如，if），接著鍵入補全快捷鍵（默認 <tab>），然后 UltiSnips 根據你鍵入的模板名在代碼模板文件中搜索匹配的“模板名-模板”，找到對應模板后，將模板在光標當前位置展開。

UltiSnips 有一套自己的代碼模板語法規則，類似：

snippet if "if statement" i if (${1:/* condition */}) { ${2:TODO} } endsnippet

其中，snippet 和 endsnippet 用于表示模板的開始和結束；if 是模板名；"if statement" 是模板描述，你可以把多個模板的模板名定義成一樣（如，if () {} 和 if () {} else {} 兩模板都定義成相同模板名 if），在模板描述中加以區分（如，分別對應 "if statement" 和 "if-else statement"），這樣，在 YCM（重量級智能補全插件） 的補全列表中可以根據模板描述區分選項不同模板；i 是模板控制參數，用于控制模板補全行為，具體參見“快速編輯結對符”一節；${1}、${2} 是 <tab> 跳轉的先后順序。

新版 UltiSnips 并未自帶預定義的代碼模板，你可以從?https://github.com/honza/vim-snippets?獲取各類語言豐富的代碼模板，也可以重新寫一套符合自己編碼風格的模板。無論哪種方式，你需要在 .vimrc 中設定該模板所在目錄名，以便 UltiSnips 尋找到。比如，我自定義的代碼模板文件 cpp.snippets，路徑為 ~/.vim/bundle/ultisnips/mysnippets/cpp.snippets，對應設置如下： let g:UltiSnipsSnippetDirectories=["mysnippets"] 其中，目錄名切勿取為 snippets，這是 UltiSnips 內部保留關鍵字；另外，目錄一定要是 ~/.vim/bundle/ 下的子目錄，也就是 vim 的運行時目錄。

完整 cpp.snippets 內容如下：

#================================= #預處理 #================================= # #include "..." snippet INC #include "${1:TODO}"${2} endsnippet # #include <...> snippet inc #include <${1:TODO}>${2} endsnippet #================================= #結構語句 #================================= # if snippet if if (${1:/* condition */}) { ${2:TODO} } endsnippet # else if snippet ei else if (${1:/* condition */}) { ${2:TODO} } endsnippet # else snippet el else { ${1:TODO} } endsnippet # return snippet re return(${1:/* condition */}); endsnippet # Do While Loop snippet do do { ${2:TODO} } while (${1:/* condition */}); endsnippet # While Loop snippet wh while (${1:/* condition */}) { ${2:TODO} } endsnippet # switch snippet sw switch (${1:/* condition */}) { case ${2:c}: { } break; default: { } break; } endsnippet # 通過迭代器遍歷容器（可讀寫） snippet for for (auto ${2:iter} = ${1:c}.begin(); ${3:$2} != $1.end(); ${4:++iter}) {${5:TODO} } endsnippet # 通過迭代器遍歷容器（只讀） snippet cfor for (auto ${2:citer} = ${1:c}.cbegin(); ${3:$2} != $1.cend(); ${4:++citer}) { ${5:TODO} } endsnippet # 通過下標遍歷容器 snippet For for (decltype($1.size()) ${2:i} = 0; $2 != ${1}.size(); ${3:++}$2) { ${4:TODO} } endsnippet # C++11風格for循環遍歷（可讀寫） snippet F for (auto& e : ${1:c}) { } endsnippet # C++11風格for循環遍歷（只讀） snippet CF for (const auto& e : ${1:c}) { } endsnippet # For Loop snippet FOR for (unsigned ${2:i} = 0; $2 < ${1:count}; ${3:++}$2) { ${4:TODO} } endsnippet # try-catch snippet try try { } catch (${1:/* condition */}) { } endsnippet snippet ca catch (${1:/* condition */}) { } endsnippet snippet throw th (${1:/* condition */}); endsnippet #================================= #容器 #================================= # std::vector snippet vec vector<${1:char}> v${2}; endsnippet # std::list snippet lst list<${1:char}> l${2}; endsnippet # std::set snippet set set<${1:key}> s${2}; endsnippet # std::map snippet map map<${1:key}, ${2:value}> m${3}; endsnippet #================================= #語言擴展 #================================= # Class snippet cl class ${1:`Filename('$1_t', 'name')`} { public: $1 (); virtual ~$1 (); private: }; endsnippet #================================= #結對符 #================================= # 括號 bracket snippet b "bracket" i (${1})${2} endsnippet # 方括號 square bracket，設定為 st 而非 sb，避免與 b 沖突 snippet st "square bracket" i [${1}]${2} endsnippet # 大括號 brace snippet br "brace" i { ${1} }${2} endsnippet # 單引號 single quote，設定為 se 而非 sq，避免與 q 沖突 snippet se "single quote" I '${1}'${2} endsnippet # 雙引號 quote snippet q "quote" I "${1}"${2} endsnippet # 指針符號 arrow snippet ar "arrow" i ->${1} endsnippet # dot snippet d "dot" i .${1} endsnippet # 作用域 scope snippet s "scope" i ::${1} endsnippet

默認情況下，UltiSnips 模板補全快捷鍵是 <tab>，與后面介紹的 YCM 快捷鍵有沖突，所有須在 .vimrc 中重新設定：

" UltiSnips 的 tab 鍵與 YCM 沖突，重新設定 let g:UltiSnipsExpandTrigger="<leader><tab>" let g:UltiSnipsJumpForwardTrigger="<leader><tab>" let g:UltiSnipsJumpBackwardTrigger="<leader><s-tab>"

效果如下：

（模板補全）

5.3 智能補全

真的，這絕對是 G 點。智能補全是提升編碼效率的殺手锏。試想下，有個函數叫 getCountAndSizeFromRemotefile()，當你輸入 get 后 IDE 自動幫你輸入完整的函數名，又如，有個文件 ~/this/is/a/deep/dir/file.txt，就像在 shell 中一樣，鍵入 tab 鍵自動補全文件路徑那是何等愜意！

智能補全有兩類實現方式：基于標簽的、基于語義的。

基于標簽的智能補全

前面代碼導航時介紹過標簽，每個標簽項含有標簽名、作用域等等信息，當鍵入某幾個字符時，基于標簽的補全插件就在標簽文件中搜索匹配的標簽項，并羅列出來，你選擇中意的，這與前面代碼導航類似，一個是用于跳轉、一個用于輸入。基于標簽的補全，后端 ctags 先生成標簽文件，前端采用插件 new-omni-completion（內置）進行識別。這種方式操作簡單、效果不錯，一般來說兩步搞定。

第一步，生成標簽文件。在工程目錄的根目錄執行 ctags，該目錄下會多出個 tags 文件；

第二步，引入標簽文件。在 vim 中引入標簽文件，在 vim 中執行命令

:set tags+=/home/your_proj/tags

后續，在編碼時，鍵入標簽的前幾個字符后依次鍵入 ctrl-x ctrl-o 將羅列匹配標簽列表、若依次鍵入 ctrl-x ctrl-i 則文件名補全、ctrl-x ctrl-f 則路徑補全。

舉個例子，演示如何智能補全 C++ 標準庫。與前面介紹的一般步驟一樣，先調用 ctags 生成標準庫的標簽文件，再在 vim 中引入即可，最后編碼時由相應插件實時搜索標簽文件中的類或模板，顯示匹配項：

首先，獲取 C++ 標準庫源碼文件。安裝的 GNU C++ 標準庫源碼文件，openSUSE 可用如下命令：

zypper install libstdc++48-devel

安裝成功后，在 /usr/include/c++/4.8/ 可見到所有源碼文件；

接著，執行 ctags 生成標準庫的標簽文件：

cd /usr/include/c++/4.8 ctags -R --c++-kinds=+l+x+p --fields=+iaSl --extra=+q --language-force=c++ -f stdcpp.tags

然后，讓 OmniCppComplete 成功識別標簽文件中的標準庫接口。C++ 標準庫源碼文件中使用了 _GLIBCXX_STD 名字空間（GNU C++ 標準庫的實現是這樣，如果你使用其他版本的標準庫，需要自行查找對應的名字空間名稱），標簽文件里面的各個標簽都嵌套在該名字空間下，所以，要讓 OmniCppComplete 正確識別這些標簽，必須顯式告知 OmniCppComplete 相應的名字空間名稱。在.vimrc中增加如下內容：

let OmniCpp_DefaultNamespaces = ["_GLIBCXX_STD"]

最后，在 vim 中引入該標簽文件。在 .vimrc 中增加如下內容：

set tags+=/usr/include/c++/4.8/stdcpp.tags

后續你就可以進行 C++ 標準庫的代碼補全，比如，在某個 string 對象名輸入 . 時，vim 自動顯示成員列表。如下圖所示：

（基于標簽的 C++ 標準庫補全）

沒明白？ -。-# 咱再來個例子，看看如何補全 linux 系統 API。與前面的標準庫補全類似，唯一需要注意，linux 系統 API 頭文件中使用了 GCC 編譯器擴展語法，必須告訴 ctags 在生成標簽時忽略之，否則將生產錯誤的標簽索引。

首先，獲取 linux 系統 API 頭文件。openSUSE 可用如下命令：

zypper install linux-glibc-devel

安裝成功后，在 /usr/include/ 中可見相關頭文件；

接著，執行 ctags 生成系統 API 的標簽文件。linux 內核采用 GCC 編譯，為提高內核運行效率，linux 源碼文件中大量采用 GCC 擴展語法，這影響 ctags 生成正確的標簽，必須借由 ctags 的 -I 命令參數告之忽略某些標簽，若有多個忽略字符串之間用逗號分割。比如，在文件 unistd.h 中幾乎每個API聲明中都會出現 __THROW、__nonnull 關鍵字，前者目的是告訴 GCC 這些函數不會拋異常，盡量多、盡量深地優化這些函數，后者目的告訴 GCC 凡是發現調用這些函數時第一個實參為 nullptr 指針則將其視為語法錯誤，的確，使用這些擴展語法方便了我們編碼，但卻影響了 ctags 正常解析，這時可用 -I __THROW,__nonnull 命令行參數讓 ctags 忽略這些語法擴展關鍵字：

cd /usr/include/ ctags -R --c-kinds=+l+x+p --fields=+lS -I __THROW,__nonnull -f sys.tags

最后，在 vim 中引入該標簽文件。在 .vimrc 中增加如下內容：

set tags+=/usr/include/sys.tags

從以上兩個例子來看，不論是 C++ 標準庫、boost、ACE這些重量級開發庫，還是 linux 系統 API 均可遵循“下載源碼（至少包括頭文件）-執行 ctags 生產標簽文件-引入標簽文件”的流程實現基于標簽的智能補全，若有異常，唯有如下兩種可能：一是源碼中使用了名字空間，借助 OmniCppComplete 插件的 OmniCpp_DefaultNamespaces 配置項解決；一是源碼中使用了編譯器擴展語法，借助 ctags 的 -I 參數解決（上例僅列舉了少量 GCC 擴展語法，此外還有 __attribute_malloc__、__wur 等等大量擴展語法，具體請參見 GCC 手冊。以后，如果發現某個系統函數無法自動補全，十有八九是頭文件中使用使用了擴展語法，先找到該函數完整聲明，再將其使用的擴展語法加入 -I 列表中，最后運行 ctags 重新生產新標簽文件即可）。

基于語義的智能補全

對于智能補全只有輕度需求的用戶來說，基于標簽的補全能夠很好地滿足需求，但對于我這類重度需求用戶來說，但凡涉及標簽，就存在以下幾個問題：

• 問題一，必須定期調用 ctags 生成標簽文件。代碼在不停更新，每次智能補全前你得先手動生成標簽文件，這還好，你可以借助前面的 indexer 在保存文件時更新標簽文件；麻煩的是，你代碼中要用到 C++ 標準庫中的接口吧，那么事前你先得對整個標準庫生成標簽文件，這也還好，無非多個步驟；更昏人的是，你得使用了編譯器語法擴展的庫，你還得一條條找出具體使用了哪些擴展語言，再讓 ctags 忽略執行語法關鍵字，真有夠麻煩的；
• 問題二，ctags 本身對 C++ 支持有限。面對函數形參、重載操作符、括號初始化的對象，ctags 有心無力；對于 C++11 新增 lambda 表達式、auto 類型推導更是不認識。

我需要更優的補全機制 —— 基于語義的智能補全。語義補全，實時探測你是否有補全需求，無須你定期生成標簽，可解決問題一；語義補全，是借助編譯器進行代碼分析，只要編譯器對 C++ 規范支持度高，不論標準庫、類型推導，還是 boost 庫中的智能指針都能補全。什么是語義分析補全？看下圖：

（語義分析補全）

代碼中定義的 TCandyBar 類型只包括 3 個成員，但 clang_complete 能補全編譯器根據 C++ 規范自動添加的兩個重載操作符、一個默認構造函數、一個析構函數，這就是基于語義分析的智能補全。

要進行語義分析，編譯器必不可少。linux 上 GCC 和 clang 兩大主流 C++ 編譯器，基于不同編譯器，開源社區分別創造出 GCCSense 和 clang_complete 兩個語義補全插件，又得糾結選哪個 -。- ... <穿越> 請跳轉至“源碼安裝編譯器 clang”部分做兩件事，一是按介紹安裝好最新版 clang 及其標準庫，二是看明白 clang 相較 GCC 的優勢 </穿越> ...

我選 clang_complete，原因如下：

• 使用難度低。clang 采用低耦合設計，語義分析結果（也就是 AST）能以接口形式供外圍程序使用，無須任何調整，clang_complete 便能能輕松拿到 clang 輸出的語義分析結果；而 GCC 采用高耦合設計，你必須結合補丁重新源碼編譯 GCC，才能讓 GCCSense 接收到它的語義分析結果；
• 維護時間長。clang_complete 最新更新為 13 年上，而 GCCSense 則是 09 年下；
• 支持跨平臺。clang_complete 支持所有平臺，而 GCCSense 支持 UNIX-like，不支持 windows。（好啦，這點是我湊數的，我又不用 windows <_<）

clang_complete 使用簡單，在 vim 輸入模式下，依次鍵入要補全的字符，需要彈出補全列表時，手工輸入 <leader>tab。比如有如下代碼片斷：

string name_yang = "yangyang.gnu"; string name_wang = "wangwang";

我要補全這兩個對象，可以先鍵入 n <leader>tab，這時 clang_complete 將羅列出所有以 n 開頭的待選項，接著輸入 ame_ 后剩下 name_yang 和 name_wang 兩項，按需選擇即可。

到這個節目眼上，我應該先給出 clang_complete 的下載地址，再告訴你如何配置 .vimrc，然后給個截圖收工，但是、但是，你知道我是個糾結癥+完美癥重度患者，雖然 clang_complete 相較 ctags+new-omni-completion 的模式有了質的飛躍，仍有雕琢余地：

• 無法隨鍵而全。補全動作有感知，要彈出候選列表菜單還得鍵入 <leader>tab，我希望插件能自動感知我的補全需求；
• 無法模糊搜索。上例中，鍵入的字符要是少了那要出來一堆待選項，選起來眼睛累，多鍵入幾個字符倒是可以讓選項少些，但輸入多了手又累。這是由于 clang_complete 采用的順序匹配算法，只要改用子序列匹配算法（模糊搜索算法的一種）即可搞定，這樣，我鍵入 ny 就只出現 name_yang，鍵入 nw 出現 name_wang；
• 無法高速補全。補全列表速度不夠快，clang_complete 由 python 編寫，生成補全列表的速度有一定影響，再加上整個補全動作是在 vim GUI 主線程中執行，所以有時會導致 GUI 假死，我需要由靜態語言編寫插件內核、動態語言作為粘合劑的補全插件，提升效率；

什么叫所需即所獲？就是當你需要什么功能，它就能給你什么功能。YouCompleteMe（后簡稱 YCM，https://github.com/Valloric/YouCompleteMe?），一個隨鍵而全的、支持模糊搜索的、高速補全的插件，太棒了！YCM 由 google 公司搜索項目組的軟件工程師 Strahinja Val Markovic 所開發，YCM 后端調用 libclang（以獲取 AST，當然還有其他語言的語義分析庫，我不關注）、前端由 C++ 開發（以提升補全效率）、外層由 python 封裝（以成為 vim 插件），它可能是我見過安裝最復雜的 vim 插件了。有了 YCM，基本上 clang_complete、AutoComplPop、Supertab、neocomplcache、UltiSnips、 Syntastic 可以再見了。

要運行 YCM，需要 vim 版本至少達到 7.3.598，且支持 python2/3，參照“源碼安裝編輯器 vim”部分可滿足；

YCM 含有與 vim 交互的插件部分，以及與 libclang 交互的自身共享庫兩部分，整個安裝過程如下：

第一步，通過 vundle 安裝 YCM 插件：

Plugin 'Valloric/YouCompleteMe'

隨后進入 vim 執行 :PluginInstall。

第二步，下載 libclang。你系統中可能已有現成的 libclang（自行源碼編譯或者發行套件中自帶的），最好別用，YCM 作者強烈建議你下載 LLVM 官網的提供預編譯二進制文件，以避免各種妖人問題。在?http://llvm.org/releases/download.html?找到最新版 LLVM，Pre-built Binaries 下選擇適合你發行套件的最新版預編譯二進制文件，下載并解壓至 ~/downloads/clang+llvm；

第三步，編譯 YCM 共享庫：

zypper --no-refresh se python-devel python3-devel boost-devel llvm-clang-devel cd ~/downloads/ mkdir ycm_build cd ycm_build cmake -G "Unix Makefiles" -DUSE_SYSTEM_BOOST=ON -DPATH_TO_LLVM_ROOT=~/downloads/clang+llvm/ .\~/.vim/bundle/YouCompleteMe/third_party/ycmd/cpp cmake --build . --target ycm_core

在 ~/.vim/bundle/YouCompleteMe/third_party/ycmd 中將生成 ycm_client_support.so、ycm_core.so、libclang.so 等三個共享庫文件；

按照慣例，我該介紹 YCM 的設置。

設置一，YCM 后端調用 libclang 進行語義分析，而 libclang 有很多參數選項（如，是否支持 C++11 的 -std=c++11、是否把警告視為錯誤的 -Werror），必須有個渠道讓 YCM 能告知 libclang，這可以在 .vimrc 中增加一個全局配置，但我有多個工程，每個工程使用的 libclang 參數選項不同豈不是每次都要調整 .vimrc？！YCM 采用更具彈性的方式，每個工程有一個名為 .ycm_extra_conf.py 的私有配置文件，在此文件中寫入工程的編譯參數選項。下面是個完整的例子：

import os import ycm_core flags = [ '-std=c++11', '-O0', '-Werror', '-Weverything', '-Wno-documentation', '-Wno-deprecated-declarations', '-Wno-disabled-macro-expansion', '-Wno-float-equal', '-Wno-c++98-compat', '-Wno-c++98-compat-pedantic', '-Wno-global-constructors', '-Wno-exit-time-destructors', '-Wno-missing-prototypes', '-Wno-padded', '-Wno-old-style-cast','-Wno-weak-vtables','-x', 'c++', '-I', '.', '-isystem', '/usr/include/', ] compilation_database_folder = '' if compilation_database_folder: database = ycm_core.CompilationDatabase( compilation_database_folder ) else: database = None SOURCE_EXTENSIONS = [ '.cpp', '.cxx', '.cc', '.c', '.m', '.mm' ] def DirectoryOfThisScript(): return os.path.dirname( os.path.abspath( __file__ ) ) def MakeRelativePathsInFlagsAbsolute( flags, working_directory ): if not working_directory: return list( flags ) new_flags = [] make_next_absolute = False path_flags = [ '-isystem', '-I', '-iquote', '--sysroot=' ] for flag in flags: new_flag = flag if make_next_absolute: make_next_absolute = False if not flag.startswith( '/' ): new_flag = os.path.join( working_directory, flag ) for path_flag in path_flags: if flag == path_flag: make_next_absolute = True break if flag.startswith( path_flag ): path = flag[ len( path_flag ): ] new_flag = path_flag + os.path.join( working_directory, path ) break if new_flag: new_flags.append( new_flag ) return new_flags def IsHeaderFile( filename ): extension = os.path.splitext( filename )[ 1 ] return extension in [ '.h', '.hxx', '.hpp', '.hh' ] def GetCompilationInfoForFile( filename ): if IsHeaderFile( filename ): basename = os.path.splitext( filename )[ 0 ] for extension in SOURCE_EXTENSIONS: replacement_file = basename + extension if os.path.exists( replacement_file ): compilation_info = database.GetCompilationInfoForFile( replacement_file ) if compilation_info.compiler_flags_: return compilation_info return None return database.GetCompilationInfoForFile( filename ) def FlagsForFile( filename, \*\*kwargs ): if database: compilation_info = GetCompilationInfoForFile( filename ) if not compilation_info: return None final_flags = MakeRelativePathsInFlagsAbsolute( compilation_info.compiler_flags_, compilation_info.compiler_working_dir_ ) else: relative_to = DirectoryOfThisScript() final_flags = MakeRelativePathsInFlagsAbsolute( flags, relative_to ) return { 'flags': final_flags, 'do_cache': True }

基本上，根據你工程情況只需調整 .ycm_extra_conf.py 的 flags 部分，前面說過， flags 用于 YCM 調用 libclang 時指定的參數，通常應與構建腳本保持一致（如，CMakeLists.txt）。flags 會產生兩方面影響，一是影響 YCM 的補全內容、一是影響代碼靜態分析插件 syntastic 的顯示結果（詳見后文“靜態分析器集成”）。另外，你得注意，該配置文件其實就是個 python 腳本，python 把縮進視為語法，如果你是直接拷貝文中的 .ycm_extra_conf.py 小心縮進部分。

設置二，在 .vimrc 中增加如下配置信息：

" YCM 補全菜單配色 " 菜單 highlight Pmenu ctermfg=2 ctermbg=3 guifg=#005f87 guibg=#EEE8D5 " 選中項 highlight PmenuSel ctermfg=2 ctermbg=3 guifg=#AFD700 guibg=#106900 " 補全功能在注釋中同樣有效 let g:ycm_complete_in_comments=1 " 允許 vim 加載 .ycm_extra_conf.py 文件，不再提示 let g:ycm_confirm_extra_conf=0 " 開啟 YCM 標簽補全引擎 let g:ycm_collect_identifiers_from_tags_files=1 " 引入 C++ 標準庫tags set tags+=/data/misc/software/misc./vim/stdcpp.tags " YCM 集成 OmniCppComplete 補全引擎，設置其快捷鍵 inoremap <leader>; <C-x><C-o> " 補全內容不以分割子窗口形式出現，只顯示補全列表 set completeopt-=preview " 從第一個鍵入字符就開始羅列匹配項 let g:ycm_min_num_of_chars_for_completion=1 " 禁止緩存匹配項，每次都重新生成匹配項 let g:ycm_cache_omnifunc=0 " 語法關鍵字補全 let g:ycm_seed_identifiers_with_syntax=1

其中大部分內容從注釋就能了解，粗體配置項見下文。

YCM 集成了多種補全引擎：語義補全引擎、標簽補全引擎、OmniCppComplete 補全引擎、其他補全引擎。

YCM 的語義補全。YCM 不會在每次鍵入事件上觸發語義補全，YCM 作者認為這會影響補全效率而且沒什么必要（我持保留意見），YCM 只在如下兩種場景下觸發語義補全：一是補全標識符所在文件必須在 buffer 中（即，文件已打開）；一是在對象后鍵入 .、指針后鍵入 ->、名字空間后鍵入 ::。如下圖所示：

（YCM 的語義補全）

上圖中，我先嘗試補全類 MyClass 失敗，接著我把 MyClass 所在的文件 MyClass.h 打開后切回 main.cpp 再次補全類 MyClass 成功，然后在對象 mc 后鍵入 . 進行成員補全；

YCM 的標簽補全。語義補全的確強大，但受限挺多，如果我要補全 STL 中的泛型算法 count_if() 豈不是還要先打開庫頭文件 algorithm？不用，YCM 也支持標簽補全。要使用標簽補全，你需要做兩件事：一是讓 YCM 啟用標簽補全引擎、二是引入 tag 文件，具體設置如下：

" 開啟 YCM 標簽引擎 let g:ycm_collect_identifiers_from_tags_files=1 " 引入 C++ 標準庫tags set tags+=/data/misc/software/misc./vim/stdcpp.tags

其中，工程自身代碼的標簽可借助 indexer 插件自動生成自動引入，但由于 YCM 要求 tag 文件中必須含有 language:<X> 字段（ctags 的命令行參數 --fields 必須含有 l 選項），所有必須通過 indexer_ctagsCommandLineOptions 告知 indexer 調用 ctags 時注意生成該字段，具體設置參見“代碼導航”章節；前面章節介紹過如何生成、引入 C++ 標準庫的 tag 文件，設置成正確路徑即可。另外，由于引入過多 tag 文件會導致 vim 變得非常緩慢，我的經驗是，只引入工程自身（indexer 自動引入）和 C++ 標準庫的標簽（上面配置的最后一行）。如下圖所示：

（YCM 的標簽補全）

YCM 的 OmniCppComplete 補全引擎。我要進行 linux 系統開發，打開系統函數頭文件覺得麻煩（也就無法使用 YCM 的語義補全），引入系統函數 tag 文件又影響 vim 速度（也就無法使用 YCM 的標簽補全），這種情況又如何讓 YCM 補全呢？WOW，別擔心，YCM 還有 OmniCppComplete 補全引擎，只要你在當前代碼文件中 #include 了該標識符所在頭文件即可。通過 OmniCppComplete 補全無法使用 YCM 的隨鍵而全的特性，你需要手工告知 YCM 需要補全，OmniCppComplete 的默認補全快捷鍵為 <C-x><C-o>，不太方便，我重新設定為 <leader>;，如前面配置所示：

inoremap <leader>; <C-x><C-o>

比如，我要補全 fork()，該函數所在頭文件為 unistd.h，正確添加 #include <unistd.h> 后即可補全。如下圖所示：

（YCM 的 OmniCppComplete 補全引擎）

其實，只要你正確插入頭文件，YCM 的 OmniCppComplete 補全引擎可以替代語義引擎和標簽引擎，比如，上面的 MyClass 在不打開 MyClass.h 情況下也可由OmniCppComplete（鍵入 <leader>;）補全：

（OmniCppComplete 替代語義、標簽補全）

YCM 的其他補全。YCM 還集成了其他輔助補全引擎，可以補全路徑、頭文件、甚至可以在注釋中繼續補全。如下圖：

（YCM 的其他補全）

從我的經驗來看，要想獲得最好的補全體驗，你應綜合使用 YCM 的各種補全引擎！

另外，YCM 不愧是 google 工程師開發的，它的匹配項搜索方式非常智能，你無須從前往后逐一輸入，YCM 會對你輸入的內容進行模糊搜索，如下：

（YCM 模糊搜索）

此外，YCM 對大小寫也非常智能，當你輸入全小寫時 YCM 對大小寫不敏感，當然輸入中有大寫字母時 YCM 對大小寫敏感：

（YCM 大小寫智能敏感）

上圖中，當我鍵入 tia 時這兩個對象均匹配，接著輸入大寫 L 時就只剩 This_Is_A_Long_Name 匹配。

5.4 由接口快速生成實現框架

在 *.h 中寫成員函數的聲明，在 *.cpp 中寫成員函數的定義，很麻煩，我希望能根據類聲明自動生成類實現的代碼框架 —— vim-protodef（https://github.com/derekwyatt/vim-protodef?）。vim-protodef 依賴 FSwitch（https://github.com/derekwyatt/vim-fswitch?），請一并安裝。請增加如下設置信息：

" 成員函數的實現順序與聲明順序一致 let g:disable_protodef_sorting=1

protodef 根據文件名進行關聯，比如，MyClass.h 與 MyClass.cpp 是一對接口和實現文件，MyClass.h 中接口為：

" 設置 pullproto.pl 腳本路徑 let g:protodefprotogetter='~/.vim/bundle/protodef/pullproto.pl' " 成員函數的實現順序與聲明順序一致 let g:disable_protodef_sorting=1

pullproto.pl 是 protodef 自帶的 perl 腳本，默認位于 ~/.vim 目錄，由于改用 pathogen 管理插件，所以路徑需重新設置。

protodef 根據文件名進行關聯，比如，MyClass.h 與 MyClass.cpp 是一對接口和實現文件，MyClass.h 中接口為：

class MyClass {public:void printMsg (int = 16);virtual int getSize (void) const;virtual void doNothing (void) const = 0;virtual ~MyClass ();private:int num_; };

在 MyClass.cpp 中生成成員函數的實現框架，如下圖所示：

（接口生成實現）

MyClass.cpp 中我鍵入 protodef 定義的快捷鍵 <leader>PP，自動生成了函數框架。

上圖既突顯了 protodef 的優點：優點一，virtual、默認參數等應在函數聲明而不應在函數定義中出現的關鍵字，protodef 已為你過濾；優點二：doNothing() 這類純虛函數不應有實現的自動被 protodef 忽略。同時也暴露了 protodef 問題：printMsg(int = 16) 的函數聲明變更為 printMsg(unsigned)，protodef 無法自動為你更新，它把更改后的函數聲明視為新函數添加在實現文件中，老聲明對應的實現仍然保留。

關于缺點，先我計劃優化下 protodef 源碼再發給原作者，后來想想，protodef 借助 ctags 代碼分析實現的，本來就存在某些缺陷，好吧，后續我找個時間寫個與 protodef 相同功能但對 C++ 支持更完善的插件，內部當然借助 libclang 啦。

另外，每個人都有自己的代碼風格，比如，return 語句我喜歡

return(TODO);

所以，調整了 protodef.vim 源碼，把 239、241、244、246 四行改為

call add(full, " return(TODO);")

比如，函數名與形參列表間習慣添加個空格

void MyClass::getSize (void);

所以，把 217 行改為

let proto = substitute(proto, '(\_.*$', ' (' . params . Tail, '')

5.5 庫信息參考

有過 win32 SDK 開發經驗的朋友對 MSDN 或多或少有些迷戀吧，對于多達 7、8 個參數的 API，如果沒有一套函數功能描述、參數講解、返回值說明的文檔，那么軟件開發將是人間煉獄。別急，vim 也能做到。

要使用該功能，系統中必須先安裝對應 man。安裝 linux 系統函數 man，先下載（https://www.kernel.org/doc/man-pages/download.html?），解壓后將 man1/ 至 man8/ 拷貝至 /usr/share/man/，運行 man fork 確認是否安裝成功。安裝 C++ 標準庫 man，先下載（ftp://GCC.gnu.org/pub/GCC/libstdc++/doxygen/?），選擇最新 libstdc++-api-X.X.X.man.tar.bz2，解壓后將 man3/ 拷貝至 /usr/share/man/，運行 man std::vector 確認是否安裝成功；

vim 內置的 man.vim 插件可以查看已安裝的 man，需在 .vimrc 中配置啟動時自動加載該插件：

" 啟用:Man命令查看各類man信息 source $VIMRUNTIME/ftplugin/man.vim " 定義:Man命令查看各類man信息的快捷鍵 nmap <Leader>man :Man 3 <cword><CR>

需要查看時，在 vim 中鍵入輸入 :Man fork 或者 :Man std::vector （注意大小寫）即可在新建分割子窗口中查看到函數參考信息，為了方便，我設定了快捷鍵 <Leader>man，這樣，光標所在單詞將被傳遞給 :Man 命令，不用再手工鍵入，如下圖所示：

（庫信息參考）

另外，我們編碼時通常都是先聲明使用 std 名字空間，在使用某個標準庫中的類時前不會添加 std:: 前綴，所以 vim 取到的當前光標所在單詞中也不會含有 std:: 前綴，而，C++ 標準庫所有 man 文件名均有 std:: 前綴，所以必須將所有文件的 std:: 前綴去掉才能讓 :Man 找到正確的 man 文件。在 libstdc++-api-X.X.X.man/man3/ 執行批量重命名以取消所有 man文件的 std:: 前綴：

rename "std::" "" std::\*

順便說下，很多人以為 rename 命令只是 mv 命令的簡單封裝，非也，在重命名方面，rename 太專業了，遠非 mv 可觸及滴，就拿上例來說，mv 必須結合 sed 才能達到這樣的效果。

我認為，好的庫信息參考手冊不僅有對參數、返回值的描述，還應有使用范例，上面介紹的 linux 系統函數 man 做到了，C++ 標準庫 man 還未達到我要求。所以，若有網絡條件，我更愿意選擇查看在線參考，C++ 推薦http://www.cplusplus.com/reference/?、http://en.cppreference.com/w/Cppreference:Archives?，前者范例多、后者更新勤；UNIX 推薦?http://pubs.opengroup.org/onlinepubs/9699919799/functions/contents.html?、http://man7.org/linux/man-pages/dir_all_alphabetic.html?，前者基于最新 SUS（Single UNIX Specification，單一 UNIX 規范）、后者偏重 linux 擴展。

6 工程管理

我雖不要求達不到軟件工程的高度，但基本的管理還是有必要的，比如，工程文件的管理、多文檔編輯、工程環境的保存與恢復。

6.1 工程文件瀏覽

我通常將工程相關的文檔放在同個目錄下，通過 NERDtree （https://github.com/scrooloose/nerdtree?）插件可以查看文件列表，要打開哪個文件，光標選中后回車即可在新 buffer 中打開。

安裝好 NERDtree 后，請將如下信息加入.vimrc中：

" 使用 NERDTree 插件查看工程文件。設置快捷鍵，速記：file list nmap <Leader>fl :NERDTreeToggle<CR> " 設置NERDTree子窗口寬度 let NERDTreeWinSize=32 " 設置NERDTree子窗口位置 let NERDTreeWinPos="right" " 顯示隱藏文件 let NERDTreeShowHidden=1 " NERDTree 子窗口中不顯示冗余幫助信息 let NERDTreeMinimalUI=1 " 刪除文件時自動刪除文件對應 buffer let NERDTreeAutoDeleteBuffer=1

常用操作：回車，打開選中文件；r，刷新工程目錄文件列表；I（大寫），顯示/隱藏隱藏文件；m，出現創建/刪除/剪切/拷貝操作列表。鍵入 <leader>fl 后，右邊子窗口為工程項目文件列表，如下圖所示：

（工程文件瀏覽）

6.2 多文檔編輯

vim 的多文檔編輯涉及三個概念：buffer、window、tab，這三個事物與我們常規理解意義大相徑庭。vim 把加載進內存的文件叫做 buffer，buffer 不一定可見；若要 buffer 要可見，則必須通過 window 作為載體呈現；同個看面上的多個 window 組合成一個 tab。一句話，vim 的 buffer、window、tab 你可以對應理解成視角、布局、工作區。我所用到的多文檔編輯場景幾乎不會涉及 tab，重點關注 buffer、window。

vim 中每打開一個文件，vim 就對應創建一個 buffer，多個文件就有多個 buffer，但默認你只看得到最后 buffer 對應的 window，通過插件 MiniBufExplorer（https://github.com/fholgado/minibufexpl.vim?，原始版本已停止更新且問題較多，該版本是其他人 fork 的新項目）可以把所有 buffer 羅列出來，并且可以顯示多個 buffer 對應的 window。如下圖所示：

（buffer 列表）

我在 vim 中打開了 main.cpp、CMakeLists.txt、MyClass.cpp、MyClass.h 這四個文件，最上面子窗口（buffer 列表）羅列出的 [1:main.cpp][4:CMakeLists.txt][5:MyClass.cpp][6:MyClass.h] 就是對應的四個 buffer。當前顯示了 main.cpp 和 MyClass.h 的兩個 buffer，分別對應綠色區域和橙色區域的 window，這下對 buffer 和 window 有概念了吧。圖中關于 buffer 列表再說明兩點：

• * 表示當前有 window 的 buffer，換言之，有 * 的 buffer 是可見的；! 表示當前正在編輯的 window；
• 你注意到 buffer 序號 1 和 4 不連續的現象么？只要 vim 打開一個 buffer，序號自動增一，中間不連續有幾個可能：可能一，打開了 1、2、3、4 后，用戶刪除了 2、3 兩個 buffer，剩下 1、4；可能二，先打開了其他插件的窗口（如，tagbar）后再打開代碼文件；

配置：將如下信息加入 .vimrc 中：

" 顯示/隱藏 MiniBufExplorer 窗口 map <Leader>bl :MBEToggle<cr> " buffer 切換快捷鍵 map <C-Tab> :MBEbn<cr> map <C-S-Tab> :MBEbp<cr>

操作：一般通過 NERDtree 查看工程文件列表，選擇打開多個代碼文件后，MiniBufExplorer 在頂部自動創建 buffer 列表子窗口。通過前面配置，ctrl-tab 正向遍歷 buffer，ctrl-shift-tab 逆向遍歷（光標必須在 buffer 列表子窗口外）；在某個 buffer 上鍵入 d 刪除光標所在的 buffer（光標必須在 buffer 列表子窗口內）：

（多文檔編輯）

默認時，打開的 window 占據幾乎整個 vim 編輯區域，如果你想把多個 window 平鋪成多個子窗口可以使用 MiniBufExplorer 的 s 和 v 命令：在某個 buffer 上鍵入 s 將該 buffer 對應 window 與先前 window 上下排列，鍵入 v 則左右排列（光標必須在 buffer 列表子窗口內）。如下圖所示：

（在子窗口中編輯多文檔）

圖中，通過 vim 自身的 f 名字查找 buffer 序號可快速選擇需要的 buffer。另外，編輯單個文檔時，不會出現 buffer 列表。

6.3 環境恢復*

vim 的編輯環境保存與恢復是我一直想要的功能，我希望每當重新打開 vim 時恢復：已打開文件、光標位置、undo/redo、書簽、子窗口、窗口大小、窗口位置、命令歷史、buffer 列表、代碼折疊。vim 文檔說 viminfo 特性可以恢復書簽、session 特性可以恢復書簽外的其他項，所以，請確保你的 vim 支持這兩個特性：

vim --version | grep mksession vim --version | grep viminfo

如果編譯 vim 時添加了 --with-features=huge 選項那就沒問題。

一般說來，保存/恢復環境步驟如下。

第一步，保存所有文檔：

:wa

第二步，借助 viminfo 和 session 保存當前環境：

:mksession! my.vim :wviminfo! my.viminfo

第三步，退出 vim：

:qa

第四步，恢復環境，進入 vim 后執行：

:source my.vim :rviminfo my.viminfo

具體能保存哪些項，可由 sessionoptions 指定，另外，前面幾步可以設定快捷鍵，在 .vimrc 中增加：

" 設置環境保存項 set sessionoptions="blank,buffers,globals,localoptions,tabpages,sesdir,folds,help,options,resize,winpos,winsize" " 保存 undo 歷史 set undodir=~/.undo_history/ set undofile " 保存快捷鍵 map <leader>ss :mksession! my.vim<cr> :wviminfo! my.viminfo<cr> " 恢復快捷鍵 map <leader>rs :source my.vim<cr> :rviminfo my.viminfo<cr>

這樣，簡化第二步、第四步操作。另外，sessionoptions 無法包含 undo 歷史，你得先得手工創建存放 undo 歷史的目錄（如，.undo_history/）再通過開啟 undofile 進行單獨設置，一旦開啟，每次寫文件時自動保存 undo 歷史，下次加載在文件時自動恢復所有 undo 歷史，不再由 :mksession/:wviminfo 和 :source/:rviminfo 控制。

按此操作，并不能像 vim 文檔中描述的那樣能保存所有環境，比如，書簽、代碼折疊、命令歷史都無法恢復。這和我預期存在較大差距，暫且用用吧，找個時間再深入研究！

7 工具鏈集成

既然我們要把 vim 打造成 IDE，那必須得集成編譯器、構建工具、靜態分析器、動態調試器，當然，你可能還需要版本控制、重構工具等等，我暫時還好。

7.1 編譯器/構建工具集成

先說下編譯器和構建工具。vim 再強大也只能是個優秀的編輯器而非編譯器，它能高效地完成代碼編輯工作，但必須通過其他外部命令實現將代碼轉換為二進制可執行文件；一旦工程上規模，你不可能單個單個文件編譯，這時構建工具就派上場了。

代碼編譯

GCC 是 linux 上 C/C++ 編譯器的事實標準，幾乎所有發行套件都默認安裝，它很好但不是最好：編譯錯誤提示信息可讀性不夠（特別對于 C++ 模板錯誤信息基本就是讀天書）、基于 GCC 的二次開發困難重重。我需要更優秀的 C++ 編譯器。

Stanley B. Lippman 先生所推薦宇宙最強 C++ 編譯器 —— LLVM/clang。Stanley 何許人也？不是吧，你玩 C++ 居然不認識他。C++ 世界二號人物，當年在貝爾實驗室，Bjarne Stroustrup 構思了 C++ 功能框架，Stanley Lippman 實現了第一個版本。還無感？好吧，他是《C++ Primer》的作者。說了大神，再說說大神推薦的編譯器。

LLVM 出自伊利諾伊大學研究項目，由 google 和蘋果公司贊助。LLVM 的存在只為兩個目的：一是盡可能地模塊化現有代碼以方便在此基礎上進行二次開發、一是提供比傳統構建工具鏈更好的用戶體驗。LLVM 是個很大很大的項目群，幾乎把從編譯到調試的各個構建環節都重新實現了一遍：

• 機器碼生成方面：包含 LLVM core 子項目， LLVM core 能把滿足它約定的中間語言翻譯為高質量的機器碼；
• 編譯器方面：C/C++ 編譯器 clang、接管 GCC 生成的 AST 并進行后續機器碼生成的后端編譯器 dragonegg；
• 調試器方面：增強處理模板/重載/多線程等等特性的調試器 LLDB、能根據程序 bug 生成測試用例甚至給出修正代碼的符號虛擬機 klee；
• 鏈接器方面：能更好地處理符號鏈接的鏈接器 lld；
• 標準庫方面：滿足最新 C++ 規范的高性能實現標準庫 libc++ 和 libc++ ABI、OpenCL 標準庫的高性能實現 libclc；
• 運行期環境方面：支持 OpenMP 規范的運行期環境、Java 和 .NET 的虛擬機 vmkit；
• 代碼優化方面：用于提升并行計算性能的 polly、針對內存安全檢查的調優工具 SAFECode；

顫抖吧，小伙伴們！

我們重點介紹 clang 子項目，clang 把標準 C/C++ 代碼轉換為中間語言，換言之，前端 clang + 后端 LLVM（后簡稱 LLVM/clang）就是一款可替代 GCC 的優秀編譯器。相較 GCC，LLVM/clang 有眾多優勢，尤其以下幾點：

• 錯誤信息可讀性強。能指出哪行、哪列有錯誤，并且用波浪線突顯出來；另外，盡可能給出修改建議（比如提示你是否拼寫錯誤）；最重要的是對 C++ 模板相關語法錯誤提示非常友好；（注，GCC 4.8 開始學習 clang 優化錯誤信息可讀性）
• 編譯速度快且占用資源少。編譯速度是 GCC 的 2.5 倍，內存消耗只有 GCC 的 1/5；
• 兼容且擴充 GCC。clang 支持 GCC 的所有編譯參數，也就是說，使用 GCC 開發的項目，你只需把 makefile 中使用的編譯器從 GCC 改為 clang 即可，無須大面積調整構建系統腳本即可重新編譯；另外，clang 還對 GCC 的編譯參數進行了人性化擴展，比如，GCC 無法打開所有編譯警告（-Wall、-Wextra 不夠滴），clang 只需 -Weverything；
• 高度抽象的模塊化設計。弱耦合性帶來的模塊高度復用、二次開發非常容易，比如，前面介紹的基于語義的 C/C++ 代碼補全插件 YouCompleteMe，就是借助 libclang 庫實現。

還在擔心采用 clang 編譯的源碼移到 GCC 下無法編譯？安啦，沒問題的，你無非擔心四方面：

• 編譯參數是否兼容？前面說過，clang 全面兼容 GCC，所以編譯參數完全兼容；
• 語言擴展是否兼容？只要不是像 linux 內核那樣大規模采用各種復雜語言擴展屬性，一般項目中用到的簡單擴展是沒問題的；
• 標準庫接口是否兼容？標準庫接口是 C++ 規范中指定的，根本不存在標準庫接口不兼容一說；
• 標準庫動/靜態庫符號是否兼容？你只要確保采用 clang 的標準庫頭文件對應鏈接 clang 的動態鏈接庫、采用 GCC 的標準庫頭文件對應鏈接 GCC 的動態鏈接庫的要求就不會出現問題。

在源碼安裝 clang 前，你需先自行安裝 GCC，兩個目的，一是你得有個編譯器來編譯編譯器 clang （呵呵，繞了吧），二是其他人的項目可能會用到 GCC。

下載 LLVM、clang 及輔助庫源碼：

cd ~/downloads # Checkout LLVM svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm # Checkout Clang cd llvm/tools svn co http://llvm.org/svn/llvm-project/cfe/trunk clang cd ../.. # Checkout extra Clang Tools cd llvm/tools/clang/tools svn co http://llvm.org/svn/llvm-project/clang-tools-extra/trunk extra cd ../../../.. # Checkout Compiler-RT cd llvm/projects svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt cd ../..

關掉其他應用，盡量多的系統資源留給 GCC 編譯 clang 源碼：

mkdir build cd build cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release ../llvm make && make install

接下來，你先洗個澡，再約個會，回來應該編譯好了（thinkpad T410I，CPU 奔騰雙核 P6000，MEM 4G DDRIII，耗時 2 小時）。確認下：

clang --version

玩 C/C++ 你肯定要用到標準庫。概念上，GCC 配套的標準庫涉及 libstdc++ 和 libsupc++ 兩個子庫，前者是接口層（即，上層的封裝），后者是實現層（即，底層的具體實現），對應實物文件，你得需要兩個子庫的頭文件和動態鏈接庫（*.so）。openSUSE 的安裝源中有，直接安裝頭文件

zypper in libstdc++47-devel

位于 /usr/include/c++/4.7/，接著安裝鏈接庫

zypper in libstdc++6

位于 /usr/lib/libstdc++.so.6。呃，是滴，libstdc++、libsupc++ 兩個子庫的相關文件是合并一起安裝的。

對應到 clang 的標準庫，libc++（接口層）和 libc++abi（實現層）也需要安裝頭文件和動態鏈接庫（*.so）。openSUSE 的安裝源中并無 libc++，頭文件和動態鏈接庫只能源碼安裝：

cd ~/downloads/ svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxx cd libcxx/lib ./buildit

頭文件已經生成到 ~/downloads/libcxx/include/，要讓 clang 找到必須復制到 /usr/include/c++/v1/

cp -r ~/downloads/libcxx/include/ /usr/include/c++/v1/

*.so 文件已生成 ~/downloads/libcxx/lib/libc++.so.1.0，要讓 clang 訪問必須復制到 /usr/lib/，并創建軟鏈接

ln -s ~/downloads/libcxx/lib/libc++.so.1.0 ~/downloads/libcxx/lib/libc++.so.1 ln -s ~/downloads/libcxx/lib/libc++.so.1.0 ~/downloads/libcxx/lib/libc++.so cp ~/downloads/libcxx/lib/libc++.so* /usr/lib/

類似，源碼安裝 libc++abi 的頭文件和動態鏈接庫：

cd ~/downloads/ svn co http://llvm.org/svn/llvm-project/libcxxabi/trunk libcxxabi cd libcxxabi/lib ./buildit

頭文件已經生成到 ~/downloads/libcxxabi/include/，要讓 clang 找到必須復制到 /usr/include/c++/v1/

cp -r ~/downloads/libcxxabi/include/ /usr/include/c++/v1/ \*.so 文件已生成 ~/downloads/libcxx/lib/libc++abi.so.1.0，要讓 clang 訪問必須復制到 /usr/lib/，并創建軟鏈接 ln -s ~/downloads/libcxxabi/lib/libc++abi.so.1.0 ~/downloads/libcxxabi/lib/libc++abi.so.1 ln -s ~/downloads/libcxxabi/lib/libc++abi.so.1.0 ~/downloads/libcxxabi/lib/libc++abi.so cp ~/downloads/libcxxabi/lib/libc++abi.so\* /usr/lib/

后續可以通過如下選項進行代碼編譯：

clang++ -std=c++11 -stdlib=libc++ -Werror -Weverything -Wno-disabled-macro-expansion -Wno-float-equal -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-global-constructors -Wno-exit-time-destructors -Wno-missing-prototypes -Wno-padded -Wno-old-style-cast -lc++ -lc++abi main.cpp

這一大波編譯選項很崩潰么 @_@！我來簡單說說：

• -std=c++11：使用 C++11 新特性；
• -stdlib=libc++：指定使用 clang 的標準庫頭文件 /usr/include/c++/v1/；
• -Werror：將所有編譯警告視為編譯錯誤；
• -Weverything：打開所有編譯警告選項。在 GCC 中，無法通過單個選項打開所有編譯警告，必須繁瑣的同時指定 -Wall、-Wextra、以及大量分散的其他選項，為此 clang 新增了 -Weverything。

當然，有些警告意義不大，完全可忽略，如下：

• -Wno-disabled-macro-expansion：禁止使用宏表達式，忽略此警告；
• -Wno-float-equal：浮點類型不應使用 != 和 == 運算符，忽略此警告；
• -Wno-c++98-compat、-Wno-c++98-compat-pedantic：采用 C++11 新特性的代碼無法兼容 C++98，忽略此警告；
• -Wno-global-constructors：在 main() 之前存在執行的代碼，忽略此警告；
• -Wno-exit-time-destructors：在 main() 之后存在執行的代碼，忽略此警告；
• -Wno-missing-prototypes：雖有函數定義但缺失函數原型，忽略此警告；
• -Wno-padded：結構體大小應為 4 字節整數倍，忽略此警告（編譯器自動調整對齊邊界）；
• -Wno-old-style-cast：C 語言的強制類型轉換，忽略此警告；
• -lc++：指定鏈接 /usr/lib/libc++.so 標準庫（缺失將導致鏈接失敗！）；
• -lc++abi：指定鏈接 /usr/lib/libc++abi.so 標準庫（缺失將導致鏈接失敗！）。

系統構建

對于只有單個代碼文件的項目來說，無非是保存代碼文件、shell 中調用 GCC 編譯、鏈接這樣的簡單方式即可實現；但，對于動輒幾十上百個文件的工程項目，采用這種方式只會把自己逼瘋，必須借助構建工具管理工程的整個構建過程。

linux 有兩類工程構建工具 —— Makefile系 和非 Makefile 系，Makefile 系常見構建工具有 GNU 出品的老牌 autoconf、新生代的 CMake，非 Makefile 系中最著名的要數 SCons。KDE 就是通過 CMake（http://www.cmake.org/cmake/resources/software.html?）構建出來的，易用性靈活性兼備，灑淚推薦。

一般來說，你需要先寫個名為 CMakeLists.txt 的構建腳本，然后執行 cmake CMakeLists.txt 命令將生成 Makefile 文件，最后執行 make 命令即可編譯生成可執行程序。

舉例來說，你工程包含 main.cpp 文件，要構建它，你需要執行如下步驟。

第一步，編寫 CMakeLists.txt，內容如下：

PROJECT(main) SET(SRC_LIST main.cpp) SET(CMAKE_CXX_COMPILER "clang++") SET(CMAKE_CXX_FLAGS "-std=c++11 -stdlib=libc++ -Werror -Weverything -Wno-deprecated-declarations -Wno-disabled-macro-expansion -Wno-float-equal -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-global-constructors -Wno-exit-time-destructors -Wno-missing-prototypes -Wno-padded -Wno-old-style-cast") SET(CMAKE_EXE_LINKER_FLAGS "-lc++ -lc++abi") SET(CMAKE_BUILD_TYPE Debug) ADD_EXECUTABLE(main ${SRC_LIST})

其中，PROJECT 指定工程名、SET 是 cmake 變量賦值命令、ADD_EXECUTABLE 指定生成可執行程序的名字。括號內的大寫字符串是 cmake 內部預定義變量，這是 CMakeLists.txt 腳本的重點，下面詳細講述：

• SRC_LIST 指定參與編譯的源碼文件列表，如果有多個文件請用空格隔開，如，你工程有 main.cpp、lib/MyClass.cpp、lib/MyClass.h 三個文件，那么可以指定為：
• SET(SRC_LIST main.cpp lib/MyClass.cpp)
• CMAKE_CXX_COMPILER 指定選用何種編譯器；
• CMAKE_CXX_FLAGS 設定編譯選項；
• CMAKE_EXE_LINKER_FLAGS 設定鏈接選項。一定要將 -lc++ 和 -lc++abi 獨立設定到 CMAKE_EXE_LINKER_FLAGS 變量中而不能放在 CMAKE_CXX_FLAGS，否則無法通過鏈接；
• CMAKE_BUILD_TYPE 設定生成的可執行程序中是否包含調試信息。

另外，對于編譯選項，我的原則是嚴己寬人。也就是說，在我本機上使用最嚴格的編譯選項以發現盡量多 bug，發布給其他人的源碼包使用最寬松的編譯選項以減少環境差異導致編譯失敗的可能。前面羅列出來的就是嚴格版的 CMakeLists.txt，寬松版我會考慮：編譯器改用 GCC（很多人沒裝 clang）、忽略所有編譯警告、讓編譯器進行代碼優化、去掉調試信息、添加安裝路徑等要素，具體如下：

PROJECT(main) SET(SRC_LIST main.cpp) SET(CMAKE_CXX_COMPILER "g++") SET(CMAKE_CXX_FLAGS "-std=c++11 -O3") SET(CMAKE_BUILD_TYPE Release) ADD_EXECUTABLE(porgram_name ${SRC_LIST}) INSTALL(PROGRAMS porgram_name DESTINATION /usr/bin/)

第二步，基于 CMakeLists.txt 生成 Makefile。在 CMakeLists.txt 所在目錄執行：

cmake CMakeLists.txt

執行成功的話，你將在該目錄下看到 Makefile 文件；

第三步，基于 Makefile 生成可執行程序。相同目錄下執行：

make

這一步，就是在調用編譯器進行編譯，如果存在代碼問題，修正錯誤后重新執行這一步即可，不用再次執行第一、二步。

基本上，你的新工程，可以在基于上面的 CMakeLists.txt 進行修改，執行一次第二步后，每次代碼調整只需執行第三步即可。

一鍵編譯

工程項目的構建過程游離于 vim 之外終究不那么方便，前面章節介紹的構建過程是在 shell 中執行的，全在 vim 中執行又是如何操作。第一步的創建 CMakeLists.txt 沒問題，vim 這么優秀的編輯器編輯個普通文本文件易如反掌；第二步的生成 Makefile 也沒問題，在 vim 內部通過 ! 前綴可以執行 shell 命令，:!cmake CMakeLists.txt 即可；第三步的編譯過程更沒問題，因為 vim 自身支持 make 命令，直接在 vim 中輸入 :make 命令它會調用外部 make 程序讀取當前目錄中的 Makefile 文件，完成編譯、鏈接操作。當然，一次性編譯通過的可能性很小，難免有些語法錯誤（語義錯誤只能靠調試器了），vim 將編譯器拋出的錯誤和警告信息輸出到 quickfix 中，執行 :cw 命令即可顯示 quickfix。說了這么多，概要之，先通過構建工具（CMake 可通過 CMakeLists.txt 文件，autotools 可通過 configure 文件）生成整個工程的 Makefile，再在 vim 中執行 :make，最后顯示 quickfix。

要實現一鍵編譯，無非是把這幾步映射為 vim 的快捷鍵，即：

nmap <Leader>m :wa<CR>:make<CR><CR>:cw<CR>

分解說明下，m 為設定的一鍵編譯快捷鍵，:wa<CR> 保存所有調整文檔內容，:make<CR> 調用 make 命令，后面的 <CR> 消除執行完 make 命令屏幕上“Press ENTER or type command to continue”的輸入等待提示，:cw<CR> 顯示 quickfix（僅當有編譯錯誤或警告時）。如下圖所示：

（一鍵編譯）

我新建了一個工程，編輯好 CMakeLists.txt，執行 :!cmake CMakeLists.txt，接著 <leader>m 一鍵編譯，quickfix 窗口顯示了編譯錯誤，光標自動定位到需要你解決的第一個編譯錯誤，回車后光標自動調整到該錯誤對應的代碼位置，修正后重新 <leader>r，編譯通過并運行生成的程序。

你可能會遇到，調整過的代碼能通過編譯，但是，要么在工程目錄中無法找到可執行程序，要么有程序但體現不出代碼調整的內容（就像沒調整過代碼一樣）。對于情況一，還算好，至少你曉得生成可程序失敗了，肯定哪兒出了問題，不會繼續往下新增代碼；情況二，就麻煩了，你想通過運行程序檢查剛才添加的代碼運行是否正常，以為運行的是新程序，其實，代碼調整后的新程序并未生成，運行是老程序，“哇，一切正常，往下寫新業務邏輯代碼”。導致這兩個情況的根本原因，代碼中存在鏈接錯誤導致并未正常創建新的可執行程序。bad news —— 如果編譯錯誤，quickfix 窗口會固定在底部，羅列出所有編譯過程中的所有錯誤，如果編譯正常（即便是存在鏈接錯誤），quickfix 窗口會出現“Press ENTER or type command to continue”的輸入等待提示信息，前面提過，為了省去手工輸入回車，已經在 <Leader>m 中為 :make 多綁定個回車符 <CR>，換言之，在編譯正確鏈接錯誤的情況下，你是無法查看到 quickfix 窗口的；good news —— 有兩種方式解決該問題：

• 方式一，將前面 <Leader>m 中為 :make 綁定的回車符 <CR> 去掉，即

nmap <Leader>m :wa<CR>:make<CR>:cw<CR>

• 方式二，先刪除老的可執行程序，再編譯、鏈接，發現缺失可執行程序時，再手工執行 :make，這樣，可查看具體是什么鏈接錯誤了，將如下配置信息加入 .vimrc 中：

nmap <Leader>m :!rm -rf main<CR>:wa<CR>:make<CR><CR>:cw<CR>

我選方式二。

到此，已實現一鍵編譯，要實現一鍵編譯及運行無非就在剛才的快捷鍵中追加綁定運行程序的外部命令即可。新快捷鍵設定為 <leader>g，假定生成的可執行程序名為 main，將如下配置信息加入 .vimrc 中：

nmap <Leader>g :!rm -rf main<CR>:wa<CR>:make<CR>:cw<CR><CR>:!./main<CR>

最后，再次強調實現一鍵編譯及運行的幾個前提：vim 的當前目錄必須為工程目錄、事前準備好 Makefile 文件且放于工程目錄的根目錄、生成的程序必須在工程目錄的根目錄。

7.2 靜態分析器集成

one take，中意“一次成型”，最早指歌手錄歌時一次性通過錄制，不存在發現錯誤-修正錯誤-重新錄制這樣的往返動作。one take 在編程環境中，就是一次性通過編譯，我個人很享受 one take 帶來的快感。當然，要達到 one take，不僅需要扎實的編程功底，還需要工具的輔佐 —— 代碼靜態分析器。前面介紹的神器 YCM 具備實時語法檢查的能力。在它的作用下，編碼中、編譯前，所有語法錯誤都將被抓出來并呈現給你。

YCM 的整個靜態分析過程分為如下幾步：

第一步，發現錯誤。YCM 內部調用 libclang 分析語法錯誤，通過管道傳遞給 YCM 呈現。當你保存代碼、vim 普通模式下移動光標或者安靜 2 秒，錯誤檢查后臺任務將自動啟動，若有錯誤，YCM 將接收到；

第二步，呈現錯誤。YCM 并不非立馬顯示錯誤信息，除非你觸發下次擊鍵事件，否則你看不到錯誤信息，換言之，干等是沒結果的，你必須有次擊鍵動作（沒辦法，vim 內部機制所限，后臺任務無法直接更新 GUI，所以才采用變通的擊鍵方式）。對于存在語法錯誤的代碼，在行首有個紅色的 >> 高亮顯示；

第三步，查看錯誤。好了，現在已經知道哪行代碼有問題，具體問題描述如何查看？兩種方式：一種是將光標移至問題行，vim 將在其底部顯示簡要錯誤描述；一種是將光標移至問題行，鍵入 <leader>d 后，vim 將在其底部顯示詳細錯誤描述。

如下所示：

（靜態代碼分析）

8 其他輔助

大家關注的 IDE 核心功能前面都已逐一介紹過了，有些輔助功能我認為也有必要讓你知道，不是都在提程序員人文關懷嘛，從我做起！

8.1 快速編輯結對符

平時，最讓我頭痛的字符莫過于 {}、""、[] 等這類結對符，輸入它們之所以麻煩，主要因為A）盲打很難找準它們位置，B）還得同時按住shift鍵。兩者再一疊加，非常影響我的思維。要高效輸入結對符，應該是輸入少量幾個字母（對，字母，不是字符）后 vim 自動為你輸入完整結對符，而非是我輸入一半 vim 輸入另一半（不用 delimitMate 的原因）。剛好，這在 UltiSnips 能力范圍內，只要定義好模板，可完美地解決這類問題，具體模板見上例中最后的結對符部分。

在定義結對符模板時，你應該考慮加上模板控制參數 i。默認情況下，UltiSnips 只會當模板名前是空白字符或行首時才進行模板補全，比如，定義 () 的模板如下：

snippet b "bracket" (${1})${2} endsnippet

我要調用函數 printf()，在輸入完 printf 后應該接著輸入括號模板名 b，然后輸入模板展開快捷鍵 <leader><tab>，你會發現 UltiSnips 無法幫你補全模板，因為它看到的不是 b 而是 printfb，這在模板文件中根本未定義。有一種間接解決方式是在 printf 后加個空格，再輸入 b<leader><tab> 進行補全，這就成了 printf ()，不喜歡這種編碼風格。其實，UltiSnips 的作者也注意到這個問題了，他讓你可以通過前面提過的模板控制參數 i 進行解決。重新定義 () 的模板如下：

snippet b "bracket" i (${1})${2} endsnippet

這樣，UltiSnips 只管光標前 1 個字符是否是 b，若是則補全 ()，不論 b 前是否有其他字符。類似，其他結對符模板都按此加上 i 控制參數。結對符模板完整定義參見上一節 cpp.snippets 示例。如下是幾個快速輸入結對符的演示：

（快速輸入結對符）

另外，要想高效編輯結對符，你得了解 vim 自身的某些快捷鍵。比如，有如下字符串且光標在該字符串的任意字符上，這時在命令模式下鍵入 va) 后將選中包括括號在內的整個字符串：

（快速選中結對符）

其中，v 是動作、a 是范圍、) 是結對符。結對符命令的動作包括：選中 v、復制 y、刪除 d、刪除后插入 c；結對符命令的范圍包括：含結對符 a、不含結對符 i。針對不同結對符，組合不同動作和范圍就有 4*2 種方式。比如，di{ 刪除不含結對符 {} 的字符串，va[ 將選中含結對符 [] 內的所有字符。

選中結對符內的文本是我較為頻繁的操作之一，通過諸如 vi[ 的命令可以選中當前結對符 [] 內的所有文本，這雖談不上麻煩，但每次都得去看下是 ]、)、> 還是 }，總是有點別扭。有款叫 wildfire.vim（https://github.com/gcmt/wildfire.vim?）的插件，讓我能更自然地選中結對符內的文本，有了它，我只需按下空格（你也可以設置成其他快捷鍵），自動選中光標所在區域最近的一層結對符內的文本，如果沒有結對符，則選擇最近的一個段落。

簡單設置：

" 快捷鍵 map <SPACE> <Plug>(wildfire-fuel) vmap <S-SPACE> <Plug>(wildfire-water) " 適用于哪些結對符 let g:wildfire_objects = ["i'", 'i"', "i)", "i]", "i}", "i>", "ip"]

這樣，在 vim 的命令模式下，一次空格選中最近一層結對符內的文本，兩次則選中近兩層內的文本，三次三層，依此類推；或者鍵入 3space，直接選中三層內的文本；若要取消，鍵入 shift-space 即可。另外，結對符類型也可以在 wildfire_objects 變量中指定。如下圖所示：

（快速選中結對符文本）

8.2 支持分支的 undo

undo，編輯器世界中的后悔藥，讓你有機會撤銷最近一步或多步操作，這是任何編輯器都具備的基礎功能。比如，第一步輸入 A，第二步輸入 B，第三步輸入 C，當前文本為 ABC，一次 undo 后變成 AB，再次 undo 后變成 A，顯然，每次 undo 撤銷的均是最后的一步操作，通常采用棧這種數據結構來實現 undo 功能，由于棧具有后進先出的特點，所以，功能實現起來非常自然且便捷，但同時，也引入了致命傷，無法支持分支上的 undo 操作。

還是前面的例子，分三步依次輸入完 ABC 后，一次 undo 變成 AB，這時，輸入 D，之后，無論你多少次 undo 都不可能再找回 C，究其原因，D 是徹底覆蓋了 C，而不是與 C 形成兩個分支，如下圖所示：

（不支持分支的 undo）

在我的使用場景中，非常需要在我輸入 D 后還能找回 C 的 undo 功能，即，支持分支的 undo，gundo.vim （http://sjl.bitbucket.org/gundo.vim/?）降臨。gundo.vim 采用樹這種數據結構來實現 undo，每一次編輯操作均放在樹的葉子上，每次 undo 后，先回到主干，新建分支繼續后續操作，而不是直接覆蓋，從而實現支持分支的 undo 功能。gundo.vim 要求 vim 版本不低于 v7.3 且支持 python v2.4 及以上。

如下方式設置好調用 gundo.vim 的快捷方式：

" 調用 gundo 樹 nnoremap <Leader>ud :GundoToggle<CR>

gundo.vim 非常貼心，調用它后，你會在左側看到一個分割為上下兩個區域的子窗口。上半區域以可視化方式顯示了整顆 undo 樹，同時，用 @ 標識最后一步編輯操作，用序號標識各步編輯操作的先后順序，用時長顯示每步操作距離當前消耗時間。下半區域展示了各個操作間的 diff 信息及其上下文，默認為選中那步操作與前一步操作間的 diff，鍵入 p 可以查看選中那步操作與最后一步操作（即有 @ 標識的那步）間的 diff，這對于找回多次編輯操作之前的環境非常有用。

（支持分支的 undo）

另外，我對持久保存 undo 歷史也有需求，以便讓我關閉 vim 后重新啟動也能找到先前的所有 undo 歷史，這需要你在 .vimrc 中添加：

" 開啟保存 undo 歷史功能 set undofile " undo 歷史保存路徑 set undodir=~/.undo_history/

你得先自行創建 .undo_history/。具體可參見“6.3 環境恢復”章節。

8.3 快速移動

vim 有兩類快速移動光標的方式：一類是以單詞為單位的移動，比如，w 正向移動到相鄰單詞的首字符、b 逆向移動到相鄰單詞的首字符、e 正向移動到相鄰單詞的尾字符、 ge 逆向移動到相鄰單詞的尾字符；一類是配合查找字符的方式移動，比如，fa 正向移動到第一個字符 a 處、Fa 逆向移動到第一個字符 a 處。你要在非相鄰的單詞或字符間移動，你可以配合數字參數，比如，正向移動到相隔八個單詞的首字符執行 8w、逆向移動到第四個 a 字符處執行 4Fa。

有如下文本：

backpage kcal liam jack facebook target luach ajax

假定光標在行首，需要移動到 facebook 的字符 a 處，先來數下前面有 1、2 ... 5 個 a，然后用前面所說的 5fa，唔，怎么在 jack 上呢？等等，好像數錯了，再數次 1、2 ... 6，對滴，應該是 6fa，這下對了。我的個天，不能讓哥太累，得找個插件幫忙 —— easymotion（https://github.com/Lokaltog/vim-easymotion?）。

easymotion 只做一件事：把滿足條件的位置用 [;A~Za~z] 間的標簽字符標出來，找到你想去的位置再鍵入對應標簽字符即可快速到達。比如，上面的例子，假設光標在行首，我只需鍵入 <leader><leader>fa （為避免與其他快捷鍵沖突，easymotion 采用兩次 <leader> 作為前綴鍵），所有的字符 a 都被重新標記成 a、b、c、d、e、f 等等標簽（原始內容不會改變），f 標簽為希望移動去的位置，隨即鍵入 f 即可到達。如下圖所示：

（快速移動）

類似，前面提過的 w、e、b、ge、F、j、k 等命令在 easymotion 作用下也能實現快速移動，其中，j 和 k 可跨行移動。同時，你還可以搭配 v 選中命令、d 刪除命令、y 拷貝命令，比如，v<leader><leader>fa，快速選中光標當前位置到指定字符 a 之間的文本，d<leader><leader>fa，快速刪除光標當前位置到指定字符 a 之間的文本，下圖所示：

（搭配操作命令的快速移動）

8.4 markdown 即時預覽

作為一枚熱衷開源的偽 geek，github.com 與我同在。發布在 github.com 的任何項目你得有個項目簡介，README.md，這是一種用 markdown 文書編寫語法制作的說明文檔。關于 markdown，我有兩個需求，一是 vim 要高亮顯示 markdown 語法，一是 firefox 要能渲染其語法、即時顯示更新結果。

第一個需求不是問題，新版 vim 已經集成了 markdown 語法高亮插件，無須單獨配置。

第二個需求，按照一般邏輯，應該通過 firefox 的某款插件來實現，的確，Markdown Viewer 看起來是干這個事兒的，但它響應速度緩慢、中文顯示亂碼、無法即時渲染等等問題讓我無法接受。網上倒是有些即時渲染 markdown 的網站，比如，https://stackedit.io/editor?，左側編輯右側顯示，所見即所得，但這又無法讓我使用 vim，不行。還是回到 vim 身上想辦法，vim-instant-markdown 來了。有了這款 vim 插件，一旦你啟用 vim 編輯 markdown 文檔，vim-instant-markdown 自動開啟 firefox 為你顯示 markdown 最終效果，如果你在 vim 中變更了文檔內容，vim-instant-markdown 即時渲染、firefox 同步更新，太棒了！

（markdown 即時渲染）

vim-instant-markdown（https://github.com/suan/vim-instant-markdown?） 的安裝相比其他插件較為特殊，它由 ruby 開發，所以你的 vim 必須集成 ruby 解釋器（見“1 源碼安裝編輯器 vim ”），并且安裝 pygments.rb、redcarpet、instant-markdown-d 三個依賴庫：

gem install pygments.rb gem install redcarpet # 若系統提示無 npm 命令，你需要先執行 zypper --no-refresh install nodejs npm -g install instant-markdown-d

注意，以上三條命令均要FQ。

對于重內容、輕設計的我這類人來說，markdown 簡潔的文書語法太貼心了。推薦三個網站：

• markdown 語法?http://daringfireball.net/projects/markdown/syntax
• github.com 擴展?https://guides.github.com/features/mastering-markdown/
• emoji 符號表情?http://www.emoji-cheat-sheet.com/

8.5 中/英輸入平滑切換

代碼中不可能全是英文，即便注釋是英文，用戶提示信息也多多少少得用中文吧，所以，在 vim 中輸入中文是常有的。中/英文輸入切換本身很簡單，但是，如果又與 vim 的插入模式和命令模式一糾纏，那么，這事兒就不太自然了。

比如，我在插入模式下依次輸入了中文的一二四三，本意是想輸入一二三四，下意識地鍵入 esc 切換為命令模式，鍵入 x 剪切三，再鍵入 P 將三粘貼至四前。誰知，在鍵入 x 時，由于輸入法仍保留在先前的中文狀態下，導致 vim 的命令模式無法接收到命令，必須得再次鍵入 shift 切換至英文狀態。如下圖所示：

（中文狀態讓命令模式無效）

這很不協調，我希望，在插入模式下輸入完中文，切換至命令模式后，即便先前是中文輸入狀態，也不影響我正常使用命令模式，甚至再次切回插入模式后，能保持先前的輸入狀態。來了，fcitx.vim（https://github.com/lilydjwg/fcitx.vim?）就是我要的。對，前提是你系統中用的是 fcitx 輸入法（為何不用 scim、ibus？https://github.com/yangyangwithgnu/the_new_world_linux#7.4?）。裝好這個插件后，我們再看看剛才的例子，在中文狀態下從插入模式切換至命令模式，鍵入 x、P 調整完四和三順序后，重新切換至插入模式，輸入法狀態仍保持中文。如下圖所示：

（即便中文狀態也不影響命令模式）

幾乎完美了，唯一問題是，該插件無法保證從其他程序窗口切換至 vim 后仍有效。

9 尾聲

嗷呼，經過以上調教，你的 vim 已經成為非常舒適的 C/C++ 開發環境呢。等等，重裝系統后又得折騰一次？不怕，除了 clang 等等幾個需要源碼安裝的工具外，基本上，vim 的插件和相關配置文件你可以提前備份好，裝完系統后恢復到對應目錄中即可，絲毫不費腦力。

2011 年 9 月我寫了篇《拼裝的藝術：vim 之 IDE 進化實錄》，原計劃近期（2014-09）更新下智能補全部分，后來越改越發覺原版問題太多，加之各插件推陳出新、自己對 vim 的認識加深，索性完全重新。期間，與很多朋友有過交流，有三類問題探討得最頻繁，我的觀點簡要闡述如下，后續不再歡迎、理會、回復相關問題：

• 為何不用 Code::Blocks 這類一站式 IDE？每個人的做事的出發點、性格觀念千差萬別，我不想拿 linux kernel 是 linus torvalds 用 microemacs（emacs 變種）開發的來說事兒，就我而言，迷戀 vim 的高效編輯能力、無限擴充能力，這是其他編輯器無法超越的。此外，我享受的是過程，不是結果！
• 哪個是最適合編碼的編輯器？linux 上存在兩種編輯器：神之編輯器 emacs，編輯器之神 vim。關于 emacs 與 vim 孰輕誰重之爭已是世紀話題，我無意參與其中，在我眼里，它們流淌著自由的血液、繼承著創新的基因，作為頂級編輯器，二者在這個領域都作到了極致，讓世人重新認識了編輯的本質 —— 用命令規則而非字字鍵入 —— 去完成編輯任務。emacs，偽裝成編輯器的操作系統，太雜、太重，我更喜歡專注于編輯的 vim。
• 怎樣的 IDE 才算好？對于初入開發的人員而言，Code::Blocks 是最易上手的選擇；對于我這類喜歡折騰、追求效率、愿意用腦力換體力的人來說，vim 搭配各類插件是好的 IDE；對于 Donald Knuth 這等宗師，他們站在整個系統的層面，bash 加上幾個命令行工具也是某種意義上的 IDE。所以，只要你能得心應手地完成軟件開發任務，又察覺不到工具的存在，那這就是最適合你的 IDE。

末了，寫作的過程，是知識體系完整重構的過程，理清了思路、加深了記憶。如果它再能引發你一點思緒，或許，這就是價值！

?

轉載于:https://www.cnblogs.com/jhj117/p/5531493.html

總結

以上是生活随笔為你收集整理的【转】所需即所获：像 IDE 一样使用 vim的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。