將VIM打形成強大的IDE

時間  2019-11-12
標籤 vim 形成 強大 ide 欄目 Unix 简体版
原文   原文鏈接
轉載自：所需即所獲：像 IDE 同樣使用 vim
如侵犯您的版權，請聯繫：2378264731@qq.com
-----------------------------------------------------------------------



【正文】

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

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

vi 之大道如我心之禪，
vi 之漫路即爲禪修，
vi 之命令禪印於心，
未得此道者視之怪誕，
與之爲伴者洞其真諦，
長修此道者鉅變人生。
做：reddy@lion.austin.com
譯：yangyang.gnu@gmail.com

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

（圖形環境下 IDE 總攬）

（純字符模式下 IDE 總攬）

0 vim 必知會

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

0.1 .vimrc 文件

.vimrc 是控制 vim 行爲的配置文件，位於 ~/.vimrc，不論 vim 窗口外觀、顯示字體，仍是操做方式、快捷鍵、插件屬性都可經過編輯該配置文件將 vim 調教成最適合你的編輯器。node

不少人之因此以爲 vim 難用，是由於 vim 缺乏默認設置，甚至安裝完後你連配置文件自身都找不到，不進行任何配置的 vim 的確難看、難用。不論用於代碼仍是普通文本編輯，有必要將以下基本配置加入 .vimrc 中。python

前綴鍵。各種 vim 插件幫助文檔中常常出現 ，即，前綴鍵。vim 自帶有不少快捷鍵，再加上各種插件的快捷鍵，大量快捷鍵出如今單層空間中不免引發衝突，爲緩解該問題，引入了前綴鍵 ，這樣，鍵 r 能夠配置成 r、r、r 等等多個快捷鍵。前綴鍵是 vim 使用率較高的一個鍵（最高的當屬 Esc），選一個最方便輸入的鍵做爲前綴鍵，將有助於提升編輯效率。找個無須眼睛查找、無須移動手指的鍵 —— 分號鍵，挺方便的，就在你右手小指處：linux

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

既然前綴鍵是爲快捷鍵服務的，那隨便說下快捷鍵設定原則：不一樣快捷鍵儘可能不要有同序的相同字符。好比，e 執行操做 0 和 eb 執行操做 1，在你鍵入 e 後，vim 不會當即執行操做 0，而是繼續等待用戶鍵入 b，即使你只想鍵入 e，vim 也不得不花時間等待輸入以確認是哪一個快捷鍵，顯然，這讓 e 響應速度變慢。ea 和 eb 就沒問題。ios

文件類型偵測。容許基於不一樣語言加載不一樣插件（如，C++ 的語法高亮插件與 python 的不一樣）：c++

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

快捷鍵。把 vim（非插件）經常使用操做設定成快捷鍵，提高效率：git

" 定義快捷鍵到行首和行尾
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
" 定義快捷鍵在結對符之間跳轉，助記pair
nmap <Leader>pa %

其餘。搜索、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 安裝，都不便於插件卸載、升級，後來又出現了管理插件的插件 pathogen，後文介紹。

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

1 源碼安裝編輯器 vim

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

卸載老版、下載新版（ftp://ftp.vim.org/pub/vim/unix/vim-7.4.tar.bz2 ），解壓至 ~/downloads/vim74/，源碼安裝：

cd ~/downloads/vim74/
./configure --with-features=huge --enable-rubyinterp --enable-pythoninterp --with-python-config-dir=/usr/lib/python2.7/config/ --enable-perlinterp --enable-gui=gtk2 --enable-cscope --prefix=/usr --enable-luainterp 
ake VIMRUNTIMEDIR=/usr/share/vim/vim74 && make install

其中，--enable-rubyinterp、--enable-pythoninterp、--enable-perlinterp、--enable-luainterp 等分別表示支持 ruby、python、perl、lua 編寫的插件，--enable-gui=gtk2 表示生成 gvim，--enable-cscope 支持 cscope，--with-python-config-dir=/usr/lib/python2.7/config/ 指定 python 路徑（先自行安裝 python 的頭文件 python-devel），這幾個特性很是重要，影響後面各種插件的使用。注意，你得預先安裝相關依賴庫的頭文件，python-devel、python3-devel、ruby-devel、libX11-devel、gtk-devel、gtk2-devel、gtk3-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/ 下都有各自獨立子目錄，這樣須要升級、卸載插件時，直接找到對應插件目錄變動便可。pathogen 爲此而生，它突破了 vim 只能識別 .vim/doc/、.vim/plugin/ 等等路徑的限制，你能夠在按插件名建立獨立目錄，而後將插件打包檔提取至各自插件目錄中。一般來講，你須要先建立 ~/.vim/bundle/ 目錄，bundle/ 就是之後存放各插件目錄的父目錄。

安裝：先清空 .vim/ 下的全部文件（備份？）；建立目錄 ~/.vim/bundle/pathogen/autoload/；下載 pathogen.vim（https://github.com/tpope/vim-pathogen ）至 ~/.vim/bundle/pathogen/autoload/。

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

# 將 pathogen 自身也置於獨立目錄中，需指定其路徑 
runtime bundle/pathogen/autoload/pathogen.vim
# 運行 pathogen
execute pathogen#infect()

使用：好比要安裝新插件 plugin_name，先在 ~/.vim/bundle/ 下建立目錄 plugin_name/，而後到 vim 官網下載 plugin_name 壓縮包並解壓至 ~/.vim/bundle/plugin_name/ 便可，注意不要重複包含屢次 plugin_name/ 目錄，如，~/.vim/bundle/plugin_name/plugin_name/。要卸載插件，直接刪除 plugin_name/ 插件目錄便可。另外，經過 pathogen 管理插件後，相較之前有幾點變化：

  • 切勿經過發行套件自帶的軟件管理工具安裝任何插件，否則 .vim/ 又要混亂了；
  • pathogen 沒法安裝配色主題風格，只能將主題插件手工放置於 ~/.vim/colors/；
  • 安裝 *.vba 類型插件：
:e plugin_name.vba 
:!mkdir -p ~/.vim/bundle/plugin_name 
:UseVimball ~/.vim/bundle/plugin_name
  • 生成幫助文檔：
:Helptags

非特殊狀況，後文介紹到的插件再也不累述如何安裝。

此外，你得注意插件的下載源。相同插件在 vim.org 和 github.com 上都能找到，有些插件在 vim.org 上是最新版，有些又在 github.com 上更新，好比，indexer 插件，在 vim.org上的版本是 4.15（http://www.vim.org/scripts/script.php?script_id=3221 ），而在 github.com 上的倒是 1.2（https://github.com/shemerey/vim-indexer ），因此我建議先去做者我的網站上找，沒有再在 vim.org 和 github.com 上比較哪一個的最新。甚至，同在 github.com 上都有不少重名插件，本身得稍微花時間確認下，本文中出現的插件，我都會附上最新版下載地址。還有，插件更新頻率較高，差很少每隔一季你應該看看哪些插件有推出新版本！

3 界面美化

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


（默認 vim 界面）

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

3.1 主題風格

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

前面說過，pathogen 沒法安裝主題插件，請將主題插件（僅 *.vim 文件而非插件目錄，即，solarized.vim、molokai.vim、phd.vim）拷貝至 ~/.vim/colors/，而後在 .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 語法高亮

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

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

效果以下：


（語法高亮）

上圖中 STL 容器模板類 unordered_multimap 並未高亮，對滴，vim 對 C++ 語法高亮支持不夠好（特別是 STL、C++11 新增元素），必須藉由插件 stl.vim 進行加強，下載（http://www.vim.org/scripts/script.php?script_id=4293 ）後拷貝至 ~/.vim/bundle/STL-Syntax/after/syntax/cpp/，重啓便可。效果以下：


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

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 自動幫我找到對應的實現文件，當鍵入快捷鍵，能夠在當前窗口中打開對應實現文件，也能夠在當前窗口中分裂一個子窗口顯示對應實現文件。

a.vim（https://github.com/vim-scripts/a.vim ）來了。安裝後增長配置信息：

" *.cpp 和 *.h 間切換
nmap <Leader>ch :A<CR>
" 子窗口中顯示 *.cpp 或 *.h
nmap <Leader>sch :AS<CR>

這樣，鍵入 ;ch 就能在實現文件和接口文件間切換，鍵入 ;sch 子窗口中將顯示實現文件/接口文件。以下圖所示：


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

上圖中，初始狀態先打開了接口文件 MyClass.h，鍵入 ;ch 後，vim 在新 buffer 中打開實現文件 MyClass.cpp，並在當前窗口中顯示；再次鍵入 ;ch 後，當前窗口切回接口文件；鍵入 ;sch 後，當前窗口分裂了一個子窗口顯示實現文件。

a.vim 實現原理很簡單，基於文件名進行關聯，好比，a.vim 能識別 my_class.h 與 my_class.cpp，而沒法識別 my_class.h 與 your_class.cpp。因此，你在命名文件時得注意下。

4.5 代碼收藏

源碼分析過程當中，經常須要在不一樣代碼間來回跳轉，我須要「收藏」分散在不一樣處的代碼行，以便須要查看時能快速跳轉過去，這時，vim 的書籤（mark）功能派上大用途了。

vim 書籤的使用很簡單，在你須要收藏的代碼行鍵入 mm，這樣就收藏好了，你試試，沒反應？不會吧，難道你 linux 內核編譯參數有問題，或者，vim 的編譯參數沒給全，讓我想一想，別急，喔，對了，你是指看不到書籤？對對對，書籤原本就看不到吖。這可不行，小二，來個讓書籤可視化的插件，親，來了，visual mark （https://github.com/vim-scripts/Visual-Mark ），記得好評。

visual mark 使用快捷鍵 mm 建立/刪除書籤，F2 正向遍歷書籤，Shift + F2 逆向遍歷，不太方便，得改；另外，書籤顏色很差看，得調。看看幫助如何配置，昏，沒幫助，得，直接改它的源碼吧。找到 ~/.vim/bundle/Visual-Mark/plugin/visualmark.vim，將

map <unique> <F2> <Plug>Vm_goto_next_sign
map <unique> <s-F2> <Plug>Vm_goto_prev_sign

替換成

map <unique> mn <Plug>Vm_goto_next_sign
map <unique> mp <Plug>Vm_goto_prev_sign

這樣，mn 正向遍歷書籤、mp 逆向遍歷；再將

if &bg == "dark" 
 highlight SignColor ctermfg=white ctermbg=blue guifg=white guibg=RoyalBlue3 
else 
 highlight SignColor ctermbg=white ctermfg=blue guibg=grey guifg=RoyalBlue3 
endif

替換成

if &bg == "dark" 
 highlight SignColor ctermfg=white ctermbg=blue guifg=#FD971F guibg=#1D1D1D
else 
 highlight SignColor ctermbg=white ctermfg=blue guifg=LightGreen guibg=DarkRed
endif

你能夠根據本身喜愛提取喜歡顏色的 RGB（推薦，提色工具 gpick，色卡http://www.colorschemer.com/schemes/ ），按上例設置便可。提醒下，RGB 的前綴是 # 而非 0X，別慣性思惟 ._.

效果以下：


（可視化書籤）

另外，我雖然選用了 visual mark，但不表明它完美了，對我而言，存在兩個硬傷：一是，建立的書籤沒法保存，下次打開該文件後又得從新窗口；一是，沒法在不一樣文件的書籤間跳轉。前者可藉由 vim 的 session 和 viminfo 特性解決，詳見後文「環境恢復」節，後者無解，只能先切換文件再跳轉書籤。

4.6 代碼導航

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

先了解下什麼是標籤（tag）。這可厲害了，標籤可謂是現代 IDE 的基石之一，沒有它，類/函數/對象列表、代碼補全、代碼導航、函數原型提示等等功能是不可能實現的。代碼中的類、結構、類成員、函數、對象、宏這些元素就是標籤，每一個標籤有它本身的名字、定義、類型、所在文件中的行位置、所在文件的路徑等等屬性。

編譯環節之一就是提取標籤，但因爲編譯器並未把生成的標籤輸出至文本，後來出現了專門用於生成標籤的工具 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 表示局部對象），另外，若是是函數，則有函數簽名字段，若是是成員函數，則有訪問性字段等等。

第三步，引入標籤文件。就是讓 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（http://www.vim.org/scripts/script.php?script_id=3221 ）。indexer 依賴 DfrankUtil（http://www.vim.org/scripts/script.php?script_id=3884 ）、vimprj（http://www.vim.org/scripts/script.php?script_id=3872 ）兩個插件，請一併安裝。請在 .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 ---------------
[multiple_source_proj]
/data/workplace/multiple_source_proj/
[single_source_proj]
/data/workplace/single_source_proj/
[example]
/data/workplace/example/

上例設定了四個工程的根目錄，方括號內是對應工程名，後續有新工程，直接添至該文件中便可。這樣，從以上目錄打開任何代碼文件時，indexer 便對整個目錄建立標籤文件，若代碼文件有更新，那麼在文件保存時，indexer 將自動調用 ctags 更新標籤文件，並自動引入進 vim 中。（indexer 生成的標籤文件以工程名命名，位於 ~/.indexer_files_tags/）

好了，解決了這三個問題後，vim 的代碼導航已經達到個人預期。

4.7 標籤列表

藉助代碼導航我能跟着執行流分析代碼，但我要分析指定函數實現細節怎麼辦？先找到該函數，再導航過去？我但願有個插件能把從當前代碼文件中提取出的全部標籤單獨放在一個子窗口中，最好還能按標籤類型給我分門別類，唔...唔，只有 tagbar （https://github.com/majutsushi/tagbar ） 能知足，它自動週期性調用 ctags 獲取結果。先自行安裝 tagbar，而後在 .vimrc 中增長以下信息：

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

說下 external 和 local，前面提過，ctags 默認並不會提取局部對象、函數聲明、外部對象等類型的標籤，我必須讓 tagbar 告訴 ctags 改變默認參數 —— 這就是 tagbar_type_cpp 變量存在的意義，因此纔在前面的配置信息中將外部對象和局部對象顯式將其加進 tagbar_type_cpp 中。

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


（標籤列表）

其中，注意幾個特色：

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

操做：若是從標籤找源碼，選擇對應標籤後回車便可跳至源碼中對應標籤位置；若是從源碼找標籤，在源碼中暫停幾秒鼠標和鍵盤操做，tagbar 子窗口中對應標籤將高亮；每次保存文件時或者切換到不一樣代碼文件時 tagbar 自動調用 ctags 更是標籤數據庫；tagbar 有兩種排序方式，一是按標籤名字母前後順序、一是按標籤在源碼中出現的前後順序，在 .vimrc 中我配置選用後者，鍵入 s 切換不一樣不一樣排序方式。

另外，我在想個問題：indexer 調用 ctags 生成用標籤，tagbar 也要調用 ctags 生成用標籤，爲什麼不能由其中之一輩子成標籤，另一個複用呢？我到沒細看兩個插件的實現代碼，估計是前者與 ctags 間是文件接口模式，後者與 ctags 是管道接口模式。插件多了仍是麻煩 -。-

5 代碼開發

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

5.1 快速開關注釋

須要註釋時，到每行代碼前輸入 //，取消註釋時再刪除 //，這種方式不是現代人的行爲。IDE 應該支持對選中文本塊批量（每行）添加註釋符號，反之，可批量取消。原本 vim 經過宏方式能夠支持該功能，但每次註釋時要本身錄製宏，關閉 vim 後宏沒法保存，因此有人專門編寫了一款插件 NERD Commenter（https://github.com/scrooloose/nerdcommenter ），NERD Commenter 根據編輯文檔的擴展名自適應採用何種註釋風格，如，文檔名 x.cpp 則採用 // 註釋風格，而 x.c 則是 // 註釋風格；另外，若是選中的代碼並不是整行，那麼該插件將用 // 只註釋選中部分。

經常使用操做：

  • cc，註釋當前選中文本，若是選中的是整行則在每行首添加 //，若是選中一行的部份內容則在選中部分先後添加分別 /、/；
  • cu，取消選中文本塊的註釋。

以下圖所示：


（快速開/關注釋）

另外，有時須要 ASCII art 風格的註釋，可用 DrawIt!（http://www.vim.org/scripts/script.php?script_id=40 ）。

經常使用操做：

  • :Distart，開始繪製結構化字符圖形，這時可用方向鍵繪製線條，空格鍵繪製或擦除字符；
  • :Distop，中止繪製結構化字符圖形。

以下圖所示：


（ASCII art 風格註釋）

5.2 模板補全

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

if (/* condition */) {
    TODO
}

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

UltiSnips 預約義了幾十種語言經常使用的代碼模板，位於 ~/.vim/bundle/UltiSnips/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} 是 跳轉的前後順序。

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

默認狀況下，UltiSnips 模板補全快捷鍵是 ，與後面介紹的 YCM 快捷鍵有衝突，全部須在 .vimrc 中從新設定：

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

UltiSnips 預約義了幾十種語言經常使用的代碼模板，我關注 C/C++ 的兩個文件：~/.vim/bundle/UltiSnips/UltiSnips/c.snippets 和 ~/.vim/bundle/UltiSnips/UltiSnips/cpp.snippets，顯然，前者是 C 程序的代碼模板，後者是 C++ 程序的代碼模板。我如今幾乎不寫純 C 代碼了，因此爲了之後代碼模板維護方便，我把 c.snippets 清空了，按本身習慣重寫了cpp.snippets，完整 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 (auto ${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

很簡單，根據我的偏好按需調整。效果以下：


（模板補全）

5.3 快速輸入結對符

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

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

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

我要調用函數 printf()，在輸入完 printf 後應該接着輸入括號模板名 b，而後輸入模板展開快捷鍵 ，你會發現 UltiSnips 沒法幫你補全模板，由於它看到的不是 b 而是 printfb，這在模板文件中根本未定義。有一種間接解決方式是在 printf 後加個空格，再輸入 b 進行補全，這就成了 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 種方式。好比，va{ 將選中含結對符 {} 的全部字符，di[ 刪除不含結對符 [] 的字符串。

5.4 智能補全

真的，這絕對是 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 上有兩大主流 C++ 編譯器 GCC 和 clang，基於不一樣編譯器，開源社區分別創造出 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 輸入模式下，依次鍵入要補全的字符，須要彈出補全列表時，手工輸入 tab。好比有以下代碼片段：

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

我要補全這兩個對象，能夠先鍵入 n tab，這時 clang_complete 將羅列出全部以 n 開頭的待選項，接着輸入 ame_ 後剩下 name_yang 和 name_wang 兩項，按需選擇便可。

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

  • 沒法隨鍵而全。補全動做有感知，要彈出候選列表菜單還得鍵入 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 能夠再見了。

要運行 YCM 須要幾個預備條件：

  • vim 版本至少達到 7.3.584，且支持 python2，參照「源碼安裝編輯器 vim」部分可知足；
  • 須要 clang 支持，且版本至少達到 3.3，參照「代碼編譯」部分可知足；

如今安裝 YCM：

第一步，下載 YCM 源碼包及相關依賴：

cd ~/.vim/bundle/ 
git clone https://github.com/Valloric/YouCompleteMe.git 
cd YouCompleteMe/ 
# 獲取 YCM 的依賴包
git submodule update --init --recursive

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

第三步，編譯 YCM 共享庫：

cd ~/downloads/ 
mkdir ycm_build 
cd ycm_build 
cmake -G "Unix Makefiles" -DPATH_TO_LLVM_ROOT=~/downloads/clang+llvm-3.4.2/ . ~/.vim/bundle/YouCompleteMe/third_party/ycmd/cpp
make ycm_support_libs

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

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

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

import os 
import ycm_core 
flags = [ 
    '-std=c++11', 
    '-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',
    '-x', 
    'c++', 
    '-I', 
    '.', 
    '-I', 
    '/usr/include/', 
    '-I', 
    '/usr/include/c++/4.8/'
] 
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 當心縮進部分。另外，/usr/include/c++/4.8/ 須要替換成你係統中 C++ 標準庫頭文件所在路徑；

設置二，在 .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: 字段（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 的默認補全快捷鍵爲 ，不太方便，我從新設定爲 ;，如前面配置所示：

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

好比，我要補全 fork()，該函數所在頭文件爲 unistd.h，正確添加 #include 後便可補全。以下圖所示：


（YCM 的 OmniCppComplete 補全引擎）

其實，只要你正確插入頭文件，YCM 的 OmniCppComplete 補全引擎能夠替代語義引擎和標籤引擎，好比，上面的 MyClass 在不打開 MyClass.h 狀況下也可由OmniCppComplete（鍵入 ;）補全：


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

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


（YCM 的其餘補全）

從個人經驗來看，要想得到最好的補全體驗，你應綜合使用 YCM 的各類補全引擎！

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


（YCM 模糊搜索）

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


（YCM 大小寫智能敏感）

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

固然，YCM 也有缺陷：

  • 工程所在路徑中不能有中文名，不然 YCM 報錯；
  • YCM 自身也有簡單的代碼導航功能，但只能在文件內跳轉而不能跨文件。

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

在 *.h 中寫成員函數的聲明，在 *.cpp 中寫成員函數的定義，很麻煩，我但願能根據函數聲明自動生成函數定義的框架 —— protodef（http://www.vim.org/scripts/script.php?script_id=2624 ）。protodef 依賴 FSwitch（http://www.vim.org/scripts/script.php?script_id=2590 ），請一併安裝。請增長以下設置信息：

" 設置 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 定義的快捷鍵 PP，自動生成了函數框架。

上圖既突顯了 protodef 的優勢：

  • 優勢一，virtual、默認參數等應在函數聲明而不該在函數定義中出現的關鍵字，protodef 已爲你過濾；
  • 優勢二：doNothing() 這類純虛函數不該有實現的自動被 protodef 忽略；

同時也暴露出幾個問題：

  • 缺點一，printMsg(int = 16) 的函數聲明變動爲 printMsg(unsigned)，protodef 沒法自動爲你更新，它把更改後的函數聲明視爲新函數添加在實現文件中，老聲明對應的實現仍然保留；
  • 缺點二：protodef 對函數返回值分析得彷佛有問題，int getSize(void) 聲明 int 返回值但實現框架無 return，而 void printMsg(int) 聲明無返回值反而在實現框架中出現了 return。

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

另外，每一個人都有本身的代碼風格，好比，return 語句我喜歡

return(TODO);

因此，調整了 protodef.vim 源碼，把 242 行改成

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

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

void MyClass::getSize (void);

因此，把 213 行改成

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

5.6 庫信息參考

有過 win32 SDK 開發經驗的朋友對 MSDN 或多或少有些迷戀吧，對於多達 七、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 （注意大小寫）便可在新建分割子窗口中查看到函數參考信息，爲了方便，我設定了快捷鍵 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，出現建立/刪除/剪切/拷貝操做列表。鍵入 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，序號自動增一，中間不連續有幾個可能：可能一，打開了 一、二、三、4 後，用戶刪除了 二、3 兩個 buffer，剩下 一、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 的編輯環境保存與恢復是我一直想要的功能，我但願恢復：已打開文件、光標位置、undo/redo、書籤、子窗口、窗口大小、窗口位置、命令歷史、buffer 列表、代碼摺疊。vim 文檔說藉助 viminfo（恢復書籤） 和 session（恢復除書籤外的其餘項）特性很能夠實現這個功能。請確保你的 vim 支持 +mksession 和 +viminfo 特性：

vim --version | grep session
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"
" 保存快捷鍵
map <leader>ss :mksession! my.vim<cr> :wviminfo! my.viminfo<cr>
" 恢復快捷鍵
map <leader>rs :source my.vim<cr> :rviminfo my.viminfo<cr>

這樣，簡化第二步、第四步操做。

按此操做，並不能像 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 
svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm 
cd llvm/tools 
svn co http://llvm.org/svn/llvm-project/cfe/trunk clang 
cd ../.. 
cd llvm/tools/clang/tools 
svn co http://llvm.org/svn/llvm-project/clang-tools-extra/trunk extra 
cd ../../../.. 
cd llvm/projects 
svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt 
cd ..

先關掉其餘應用，儘可能多的系統資源留給 GCC 進行編譯 clang 源碼：

mkdir build
cd build
../configure --enable-optimized CC=/usr/bin/GCC CXX=/usr/bin/g++

接下來，你先洗個澡，再約個會，回來應該編譯好了（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 -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 字節整數倍，忽略此警告（編譯器自動調整對齊邊界）；
  • -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

這一步，就是在調用編譯器進行編譯，若是存在代碼問題，修正錯誤後從新執行這一步便可，不用再次執行第1、二步。

基本上，你的新工程，能夠在基於上面的 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 保存全部調整文檔內容，:make 調用 make 命令，後面的 消除執行完 make 命令屏幕上「Press ENTER or type command to continue」的輸入等待提示，:cw 顯示 quickfix（僅當有編譯錯誤或警告時）。以下圖所示：


（一鍵編譯）

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

你可能會遇到，調整過的代碼能經過編譯，可是，要麼在工程目錄中沒法找到可執行程序，要麼有程序但體現不出代碼調整的內容（就像沒調整過代碼同樣）。對於狀況一，還算好，至少你曉得生成可程序失敗了，確定哪兒出了問題，不會繼續往下新增代碼；狀況二，就麻煩了，你想經過運行程序檢查剛纔添加的代碼運行是否正常，覺得運行的是新程序，其實，代碼調整後的新程序並未生成，運行是老程序，「哇，一切正常，往下寫新業務邏輯代碼」。致使這兩個狀況的根本緣由，代碼中存在連接錯誤致使並未正常建立新的可執行程序。bad news —— 若是編譯錯誤，quickfix 窗口會固定在底部，羅列出全部編譯過程當中的全部錯誤，若是編譯正常（即使是存在連接錯誤），quickfix 窗口會出現「Press ENTER or type command to continue」的輸入等待提示信息，前面提過，爲了省去手工輸入回車，已經在 m 中爲 :make 多綁定個回車符 ，換言之，在編譯正確連接錯誤的狀況下，你是沒法查看到 quickfix 窗口的；good news —— 有兩種方式解決該問題：

  • 方式一，將前面 m 中爲 :make 綁定的回車符 去掉，即 nmap m :wa:make:cw

  • 方式二，先刪除老的可執行程序，再編譯、連接，發現缺失可執行程序時，再手工執行 :make，這樣，可查看具體是什麼連接錯誤了，將以下配置信息加入 .vimrc 中： nmap m :!rm -rf main:wa:make:cw

我選方式二。

到此，已實現一鍵編譯，要實現一鍵編譯及運行無非就在剛纔的快捷鍵中追加綁定運行程序的外部命令便可。新快捷鍵設定爲 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，不只須要紮實的編程功底，還須要工具的輔佐 —— 代碼靜態分析器。syntastic（https://github.com/scrooloose/syntastic ），一款支持多語言的實時語法檢查插件。在 syntastic 的做用下，編碼中、編譯前，全部語法錯誤都將被抓出來並呈現給你。

因爲 YCM 已經深度集成 syntastic，因此基本上你無須配置。在 ~/.vim/bundle/syntastic/syntax_checkers/cpp/ 下你能夠看到可選的 C++ 語法檢查腳本，你能夠經過命令 :SyntasticInfo 查看當前選用的檢查腳本，應該是 ycm.vim。整個過程分爲以下幾步。

第一步，發現錯誤。YCM 內部調用 libclang 分析語法錯誤，經過管道傳遞給 syntastic 呈現。當你保存代碼或者安靜 2 秒，錯誤檢查後臺任務將自動啓動，如有錯誤，syntastic 將接收到。

第二步，呈現錯誤。syntastic 並不非立馬顯示 YCM 發過來的錯誤信息，除非你觸發下次擊鍵事件，不然你看不到錯誤信息，換言之，乾等是沒結果的，你必須有次擊鍵動做（沒辦法，vim 內部機制所限，後臺任務沒法直接更新 GUI，因此才採用變通的擊鍵方式）。對於存在語法錯誤的代碼，在行首有個紅色的 >> 高亮顯示，若是你以爲 >> 不夠醒目，你能夠參照以下方式從新設置：

let g:syntastic_error_symbol = '✗'
let g:syntastic_warning_symbol = '⚠'

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

以下所示：


（靜態代碼分析）

8 其餘輔助

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

8.1 內容查找

vim 支持正則表達式，那麼已經具備強勁的查供能力，在當前文件內查找，vim 的 / 和 ? 查找命令很是好用，但工程內查找，自帶的查找用戶體驗還沒法達到個人預期。我但願查找時直接根據光標位置肯定查找關鍵字，查詢結果經過列表形式羅列處理，選擇某項光標就能跳轉到對應位置，另外，能夠在工程範圍內查找，或者在打開文件內查找。有個叫 grep.vim（https://github.com/yegappan/grep ）的插件知足個人需求。

grep.vim 實際上提供了在 vim 內部方便使用 grep、fgrep、egrep、agrep、find、xargs等工具的接口。若是要在工程內進行查找，能夠在 vim 命令行中執行 :Grep，grep.vim 插件會依次提示輸入待查找關鍵字、待查找的文件類型，回車便可執行查找，結果將羅列在 quickfix 中（注，vim與不少外部命令、插件的交互信息都將在 quickfix 中呈現，這裏說到的搜索結果是一個例子，另一個前面「一鍵編譯」章節提到的編譯結果也將輸出至此，可用 :cw 命令打開/關閉 quickfix 窗口）。如果要突然大小寫則執行 :Grep -i，如果要遞歸搜索子目錄則執行 :Grep -r；另外，若是光標在某個字符串上，那麼 grep.vim 插件將自動提取該字符串做爲查找關鍵字。若是要在當前打開文件內查找，能夠執行 :GrepBffer 命令，參數同上。爲高效執行搜索操做，能夠設定快捷鍵：

" 使用 Grep.vim 插件在工程內全局查找，設置快捷鍵。快捷鍵速記法：search in project
nnoremap <Leader>sp :Grep -ir<CR><CR><CR>
" 使用 Grep.vim 插件在工程內全局查找，設置快捷鍵。快捷鍵速記法：search in buffer
nnoremap <Leader>sb :GrepBuffer -ir<CR><CR>

:Grep 默認須要手工確認搜索關鍵字、搜索文件類型，方便起見，我在映射命令後加了幾個連續 ，這樣就不用手工回車確認了。

舉個例子，光標移到 MyClassABC 下，鍵入 sp 後，grep.vim 自動提取 MyClassABC 爲搜索關鍵字，執行工程中內查找，找到到 4 個匹配項並顯示在 quickfix 中；接着鍵入 sb 後，執行打開文件內查找，找到 1 個匹配項。以下圖所示：


（內容查找）

8.2 內容替換

有個名爲 iFoo 的全局變量，被工程中 16 個文件引用過，因爲你岳母以爲匈牙利命名法嚴重、異常、絕對以及十分萬惡，爲討岳母歡心，不得不將該變量改名爲 foo，怎麼辦？依次打開每一個文件，逐一查找後替換？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)
    wa
    let flag = ''
    if a:confirm
        let flag .= 'gec'
    else
        let flag .= 'ge'
    endif
    let search = ''
    if a:wholeword
        let search .= '\<' . escape(expand('<cword>'), '/\.*$^~[') . '\>'
    else
        let search .= expand('<cword>')
    endif
    let 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>

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

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

" 替換函數。參數說明：
" confirm：是否替換前逐一確認
" wholeword：是否整詞匹配
" replace：被替換字符串
function! Replace(confirm, wholeword, replace)
    wa
    let flag = ''
    if a:confirm
        let flag .= 'gec'
    else
        let flag .= 'ge'
    endif
    let search = ''
    if a:wholeword
        let search .= '\<' . escape(expand('<cword>'), '/\.*$^~[') . '\>'
    else
        let search .= expand('<cword>')
    endif
    let 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，因此註釋中的關鍵字不會被替換掉。以下所示：


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

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


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

8.3 快速移動

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

有以下文本：

backpage kcal liam jack facebook target luach ajax

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

easymotion 只作一件事：把知足條件的位置用 [A~Za~z] 間的標籤字符標出來，找到你想去的位置再鍵入對應標籤字符便可快速到達。好比，上面的例子，假設光標在行首，我只需鍵入 fa （爲避免與其餘快捷鍵衝突，easymotion 採用兩次 做爲前綴鍵），全部的字符 a 都被從新標記成 a、b、c、d、e、f 等等標籤（原始內容不會改變），f 標籤爲但願移動去的位置，隨即鍵入 f 便可到達。以下圖所示：


（快速移動）

相似，前面提過的 w、e、b、ge、F、j、k 等命令在 easymotion 做用下也能實現快速移動，其中，j 和 k 可跨行移動。同時，你還能夠搭配 v 選中命令、d 刪除命令、y 拷貝命令，好比，vfa，快速選中光標當前位置到指定字符 a 之間的文本，dfa，快速刪除光標當前位置到指定字符 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 三個依賴庫（npm 命令可經過 zypper install nodejs 安裝）。

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

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。

末了，我不清楚這篇文章能幫到哪些人、幫到什麼程度，但我本身受益不淺！寫做的過程，是知識體系完整重構的過程，理清了思路、加深了記憶。若是它再能引起你的一點思緒，或許，這就是價值！

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程