使用语料库可以生成词性使用比例（比如一个单词，动词形式在语料库里使用比例30%，名词形式使用比例70%），BNC语料库配合翻译引擎可以生成单词释义比例（比如一个单词，各个含义在语料库中出现次数的比例）。
用柯林斯+COCA6万单词做索引，生成了这个释义比例词典：
截图里排在 GoldenDict 第二的词典，为了保持紧凑，没有词头和音标，只占用一行空间。希望查词时能多一个参考角度：
云盘下载（MDX）：
链接: http://pan.baidu.com/s/1kVHnu8R 密码: 5n6x
相关内容：
挺多人问怎么在 Vim 中搭建 C/C++ 开发环境，我本来想找篇文章发给人家，结果网上看了一圈，要不就是内容太过陈旧，要不就是太过零碎，不成体系。2018 年了，Vim 8 发布已经一年半，各大 Linux 发行版和 Mac OS X自带的 Vim 都已经跟进到 8了，不少文章还在介绍一些十年前的老方法。于是有了这篇文章。
那如何高效的再 Vim 8 中开发 C/C++ 项目呢？假设你已经有一定 Vim 使用经验，并且折腾过 Vim 配置，能够相对舒适的在 Vim 中编写其他代码的时候，准备在 Vim 开始 C/C++ 项目开发，或者你已经用 Vim 编写了几年 C/C++ 代码，想要更进一步，让自己的工作更加顺畅的话，本文就是为你准备的：
为什么把插件管理放在第一个来讲呢？这是比较基本的一个东西，如今 Vim 下熟练开发的人，基本上手都有 20-50 个插件，遥想十年前，Vim里常用的插件一只手都数得过来。过去我一直使用老牌的 Vundle 来管理插件，但是随着插件越来越多，更新越来越频繁，Vundle 这种每次更新就要好几分钟的东西实在是不堪重负了，在我逐步对 Vundle 失去耐心之后，我试用了 vim-plug ，用了两天以后就再也回不去 Vundle了，它支持全异步的插件安装，安装50个插件只需要一分钟不到的时间，这在 Vundle 下面根本不可想像的事情，插件更新也很快，不像原来每次更新都可以去喝杯茶去，最重要的是它支持插件延迟加载：
" 定义插件，默认用法，和 Vundle 的语法差不多
Plug 'junegunn/vim-easy-align'
Plug 'skywind3000/quickmenu.vim'
" 延迟按需加载，使用到命令的时候再加载或者打开对应文件类型才加载
Plug 'scrooloose/nerdtree', { 'on': 'NERDTreeToggle' }
Plug 'tpope/vim-fireplace', { 'for': 'clojure' }
" 确定插件仓库中的分支或者 tag
Plug 'rdnetto/YCM-Generator', { 'branch': 'stable' }
Plug 'nsf/gocode', { 'tag': 'v.20150303', 'rtp': 'vim' }
定义好插件以后一个：:PlugInstall 命令就并行安装所有插件了，比 Vundle 快捷不少，关键是 vim-plug 只有单个文件，正好可以放在我 github 上的 vim 配置仓库中，每次需要更新 vim-plug 时只需要 :PlugUpgrade，即可自我更新。
抛弃 Vundle 切换到 vim-plug 以后，不仅插件安装和更新快了一个数量级，大量的插件我都配置成了延迟加载，Vim 启动速度比 Vundle 时候提高了不少。使用 Vundle 的时候一旦插件数量超过30个，管理是一件很痛苦的事情，而用了 vim-plug 以后，50-60个插件都轻轻松松。
现在有好多 ctags 的代替品，比如 gtags, etags 和 cquery。然而我并不排斥 ctags，因为他支持 50+ 种语言，没有任何一个符号索引工具有它支持的语言多。同时 Vim 和 ctags 集成的相当好，用它依赖最少，大量基础工作可以直接通过 ctags 进行，然而到现在为止，我就没见过几个人把 ctags 用对了的。
就连配置文件他们都没写对，正确的 ctags 配置应该是：
set tags=./.tags;,.tags
这里解释一下，首先我把 tag 文件的名字从 tags 换成了 .tags，前面多加了一个点，这样即便放到项目中也不容易污染当前项目的文件，删除时也好删除，gitignore 也好写，默认忽略点开头的文件名即可。
前半部分 ./.tags; 代表在文件的所在目录下（不是 :pwd 返回的 Vim 当前目录）查找名字为 .tags 的符号文件，后面一个分号代表查找不到的话向上递归到父目录，直到找到 .tags 文件或者递归到了根目录还没找到，这样对于复杂工程很友好，源代码都是分布在不同子目录中，而只需要在项目顶层目录放一个 .tags文件即可；逗号分隔的后半部分 .tags 是指同时在 Vim 的当前目录（:pwd命令返回的目录，可以用 :cd ..命令改变）下面查找 .tags 文件。
最后请更新你的 ctags，不要再使用老旧的 Exuberant Ctags，这货停止更新快十年了，请使用最新的 Universal CTags 代替之，它在 Exuberant Ctags 的基础上继续更新迭代了近十年，如今任然活跃的维护着，功能更强大，语言支持更多。
（注意最新版 universal ctags 调用时需要加一个 –output-format=e-ctags，输出格式才和老的 exuberant ctags 兼容否则会有 windows 下路径名等小问题）。
过去写几行代码又需要运行一下 ctags 来生成索引，每次生成耗费不少时间。如今 Vim 8 下面自动异步生成 tags 的工具有很多，这里推荐最好的一个：vim-gutentags，这个插件主要做两件事情：
.git, .svn, .project 等标志性文件（可以自定义）来确定当前文档所属的工程目录。.tags 文件。每次改了几行不用全部重新生成，并且这个增量更新能够保证 .tags 文件的符号排序，方便 Vim 中用二分查找快速搜索符号。vim-gutentags 需要简单配置一下：
" gutentags 搜索工程目录的标志，碰到这些文件/目录名就停止向上一级目录递归
let g:gutentags_project_root = ['.root', '.svn', '.git', '.hg', '.project']
" 所生成的数据文件的名称
let g:gutentags_ctags_tagfile = '.tags'
" 将自动生成的 tags 文件全部放入 ~/.cache/tags 目录中，避免污染工程目录
let s:vim_tags = expand('~/.cache/tags')
let g:gutentags_cache_dir = s:vim_tags
" 配置 ctags 的参数
let g:gutentags_ctags_extra_args = ['--fields=+niazS', '--extra=+q']
let g:gutentags_ctags_extra_args += ['--c++-kinds=+px']
let g:gutentags_ctags_extra_args += ['--c-kinds=+px']
有了上面的设置，你平时基本感觉不到 tags 文件的生成过程了，只要文件修改过，gutentags 都在后台为你默默打点是否需要更新数据文件，你根本不用管，还会帮你：
setlocal tags+=...
为当前文件添加上对应的 tags 文件的路劲而不影响其他文件。得益于 Vim 8 的异步机制，你可以任意随时使用 ctags 相关功能，并且数据库都是最新的。需要注意的是，gutentags 需要靠上面定义的 project_root 里的标志，判断文件所在的工程，如果一个文件没有托管在 .git/.svn 中，gutentags 找不到工程目录的话，就不会为该野文件生成 tags，这也很合理。想要避免的话，你可以在你的野文件目录中放一个名字为 .root 的空白文件，主动告诉 gutentags 这里就是工程目录。
最后啰嗦两句，少用 CTRL-] 直接在当前窗口里跳转到定义，多使用 CTRL-W ] 用新窗口打开并查看光标下符号的定义，或者 CTRL-W } 使用 preview 窗口预览光标下符号的定义。
我自己还写过不少关于 ctags 的 vimscript，例如在最下面命令行显示函数的原型而不用急着跳转，或者重复按 ALT+; 在 preview 窗口中轮流查看多个定义，不切走当前窗口，不会出一个很长的列表让你选择，有兴趣可以刨我的 vim dotfiles 。
再 Vim 8 以前，编译和运行程序要么就让 vim 傻等着结束，不能做其他事情，要么切到一个新的终端下面去单独运行编译命令和执行命令，要么开个 tmux 左右切换。如今新版本的异步模式可以让这个流程更加简化，这里我们使用 AsyncRun 插件，简单设置下：
Plug 'skywind3000/asyncrun.vim'
" 自动打开 quickfix window ，高度为 6
let g:asyncrun_open = 6
" 任务结束时候响铃提醒
let g:asyncrun_bell = 1
" 设置 F10 打开/关闭 Quickfix 窗口
nnoremap <F10> :call asyncrun#quickfix_toggle(6)<cr>
该插件可以在后台运行 shell 命令，并且把结果输出到 quickfix 窗口：
最简单的编译单个文件，和 sublime 的默认 build system 差不多，我们定义 F9 为编译单文件:
有道词典的同近义词的词语辨析是比较好用的，能够帮你区分单词之间的细微差别，但是稍作调查就能发现，有道的《词语辨析》数据来源于以下几个公开资料：
1) 《英语同义词辨析大全》：https://wenku.baidu.com/view/16b16d4269eae009581becc6.html
2) 《易混淆词组》：https://wenku.baidu.com/view/9b9db523a5e9856a561260a2.html
3) 《考研英语近义近形词辨析》：https://wenku.baidu.com/view/678e3aa4dd36a32d737581b2.html
都是网上的公开资料，那么我们也整合一个，并且融合了网上更多的同近义词辨析公开资料，得到了这部《有道词语辨析》词典：
比如查 ample 就能显示出另外几个近义词，以及他们的区别，应该是目前同义词辨析最丰富的 mdx 词典了。
收词范围大概是从初中到研究生英语词汇量的收词范围，也就是差不多 COCA 词频排行榜 8000 以内的核心单词汇。8000 以内的词义辨析可以查这个，超过范围可以看更专业的：
这两个资料。
词典下载：
相关内容：
Bash 的知识点向来比较凌乱，有时候写点小脚本，你忘记了条件判断怎么写了，就打开网页搜索一半天；忘记怎么分割字符串，又搜索一半天；忘了怎么解压缩某后缀名，又打开网页搜一半天。
关键大部分搜出来的东西都十分琐碎，东一处，西一处，质量又参差不齐，而且看到一处有些细节有疑问，你还得接着搜索。
连记点笔记也是这一篇那一篇的，用起来找来找去的十分不爽，所以我一怒之下春节期间整理了一份 bash 的 cheatsheet，以图以后有关于 bash 的事情就查看这个文件就够了：
https://github.com/skywind3000/awesome-cheatsheets/blob/master/languages/bash.sh
对于一些工具性的东西，有时候一份速查表比你翻书查网页都高效数倍。
—
相关阅读：
（这是之前我在知乎上回答的一个可能对大家有点用处的答案，关于 zsh 的一些演示）
并不是传统基于正则表达式的色彩高亮，而是真的会判断你输入的是啥的色彩高亮：
白色代表普通命令或者程序，红色代表错误命令，这个很管用，你再一个个字母的敲命令，前面都是红色的，如果敲对了最后一个字母的话，你会看到整条命令连着前面的都变成了白色，代表你敲对了。以前无高亮的时候敲错了都不知道，还要往上翻着左右检查。下面青色的代表内建命令或者 alias （echo 和 ls ），这些都不是正则判断出来的，是真的去检查的。
细心的人会发现非零的错误码，也会高亮显示在最右边（上一条 data命令错误，返回127）。
注意，命令提示和补全是两个完全不同的系统，很多时候提示比补全更有用：
你才输入完 “tar”命令，后面就用灰色给你提示 tar 命令的参数，而且是随着你动态输入完每一个字母不断修正变化：
比如你输入到 – 后，没有跟着它上面的提示，而是输入了一个c字母，它马上明白你是要压缩，不是解压，然后随即给出你压缩对应的命令提示。
这个命令提示是基于你的历史命令数据库进行分析的，随着你输入的命令越来越多，提示将会越来越准确和顺手，某些不常输入的命令特别管用，比如偶尔查看下网卡配置：
刚输入完：cat /etc/n 它后面已经猜出你可能要查看网卡配置了，然后马上给出你提示，用不着你 tab 补全半天，你才敲 gc ，它就猜测出你可能想运行 gcc，然后马上给出完整建议：
春节期间整理了一份 Vim 中文速查表，免得经常东搜索西搜索的：
https://github.com/skywind3000/awesome-cheatsheets/blob/master/editors/vim.txt
看了一下，应该是现在 Vim 所有中英文速查表里最完善的一份，有时候速查表比看书搜网页高效多了。
无数次被问道：你在终端下怎么调试更高效？或者怎么在 Vim 里调试？好吧，今天统一回答下，我从来不在 vim 里调试，因为它还不成熟。那除了命令行 GDB 裸奔以外，终端下还有没有更高效的方法？能够让我事半功倍？
当然有，选择恰当的工具和方法，让 GDB 调试效率成倍的提升并没有任何问题。当然，前提条件是你至少会在使用最原始的 GDB。
穿上各种衣服前，至少得先学会裸奔，找份简单的 GDB cheat sheet 对照一下：
生产环境中出现崩溃时，因线上服务器一般没有开发环境，也无配套源代码，所以程序崩溃后，如果你懒得把 core 文件拖回到开发机检查，可以先在线上服务器先简单gdb看一下。
GDB命令密密麻麻，常用的也就表格上那几条，比如进去以后第一步先用 bt 查看一下调用栈，info local查看一下本地变量，再配合 up/down 在整个调用栈的不同层次之间上下移动一下，检查各处局部变量的值，print 一下某个表达式，即便没代码，看下符号和反汇编，一般也能调试个七七八八。
碰到复杂点的 BUG，必须配合源代码了，那你得把 core 文件拉到开发环境中，再用 gdb 对照源代码调试，配合 list [行号] 指令查看当前运行的源代码，再配合其他方法进行调试。
那么这时候，如果调试复杂度继续上升，你需要不断的断点，每次 next / step 单步完后你都需要 list 一下前后源代码，或者用 disassemble [函数名/地址] 查看一下指令的话，不少人会感觉到抓狂，这时我们需要给裸奔的 GDB 穿条内裤了。
这是 gdb 自带的文本界面，使用 gdb -tui 命令启动，比如：
gdb -tui hello
即可打开我们的文本界面：
上方是源代码窗口，下面是 gdb 终端，窗口管理快捷键模仿 emacs，使用 c-x o 进行窗口切换，如果你还想查看指令窗口，可以输入：layout split
然后你单步的时候上面的源代码窗口会跟着滚动，比之前不停的 list 方便不少吧，要看前后源代码可以继续 c-x o 切换窗口后上下滚动。
有时候你 up/down 切换了栈帧后，上面的代码也许来不及更新，那么你用 update 指令，让上面的代码窗口定位到你最新的执行位置，有时也需要 CTRL-L 重绘下整个界面。
在 gdb 自带的 tui 模式中，你不但可以随时查看代码/指令，还可以查看寄存器。好吧，其实 gdb再简陋，本身还是配套了一条内裤的，只是很多人忘记拿出来穿了。
如果上述文本 TUI的信息不够丰富的话，也许你会对 .gdbinit 感兴趣，~/.gdbinit 是一个 gdb配置脚本，可以设定一些由 python 编写的插件，比如 peda：
在 ~/.gdbinit 上面配置了 peda 后，可以看到命令提示符就从 (gdb) 变成了 gdb-peda$ 。每敲一个单步命令，peda 都会显示出无比丰富的信息，你还可以配置添加更多，配合高亮，你可以得到一个加强版的命令行。
不过这个我用的并不多，因为它会影响 TUI 模式的界面，我不喜欢在我的 gdb 里搞太多乱七八糟的东西。同时，当我们的调试需求继续变得更加复杂，你要不停的断点，频繁的单步，这些传统命令行里不停的输入各种指令显然已经让我们疲惫不堪了，能否直接在界面上查看源代码并且直接在代码上快捷键断点，快捷键单步呢？
可以啊，试试 cgdb。
CGDB 类似 gdb tui 分为终端窗口和代码窗口：
发几个好玩的玩具给大家新年玩玩：
⚡ cppman：C++ 98/11/14 手册查询 for Linux/MacOS
我知道你在 Windows 下有 Zeal ，你在 Mac OS X 用 Dash，但是你想在服务器上或者任意命令行环境下查看 C/C++ 语言手册么？偶尔看别人代码里调用到一个冷僻的 libc 函数（比如 strpbrk这种），网页搜索太慢，运行 zeal/dash 麻烦，想在命令行直接查看帮助怎么办？
这是个台湾小伙写的工具，使用很简单，跟 man一样，命令行输入：
cppman std::thread
即可查看 thread 相关手册
可以配置到终端编辑器里设定个快捷键，一按下去就可以显示光标下面 token 的 reference，清晰的排版，美观的着色：
关键是速度快，比你开网页查便捷多了，
Windows 下用不了，可以在 WSL/MSYS/Cygwin 下面安装了一个，编辑器里照样一键弹出对应的帮助窗口，默认是在线请求 cppreference.com / cplusplus.com 的内容，可以花半小时一次性全部缓存到本地，提供离线帮助。
（点击 more/continue 继续）