啰嗦文：为何我要用 vim

这段时间看到一个帖子，提到为何IDE如此丰富，还有人愿意用vim(或者emacs,后文我就简写vim了)
这种古老又难用的文本编辑器，就在这写写我个人的感受，也许可以给别人一点参考吧。

vim为什么被设计成这么难用

相比大多数直观的IDE而言，vim的操作是非常诡异的。想当初初学Linux时
参考网上教程用vim改完配置文件之后，又花了2个小时猜测究竟怎样才能保存结果！
最终无奈放弃，改用nano。数年之后开始学习vim，才知道原来保存文件要要冒号w !

为什么不支持通用的ctrl+s？为什么没有个菜单？怎么把编辑器设计的这么难用？
怎么这么反人类的编辑器还有人说他好？这些问题可以从计算机的发展史上找到些许答案。

在计算机发展的初期，人机交互的方式只有 "命令行" 这种最基本的形式，就如同现在
的Linux管理员使用bash一样，使用者必须输入准确的指令指导计算机完成任务，那时候
什么鼠标啦，什么直观的图形界面啦，什么易用的用户体验啦，还连影都见不到呢，
如此难上手，当然就与大众相距甚远。

诞生在那个年代的vim，理所当然的使用"命令式"操作流程，也就继承了命令式交互的优良"缺点"。
后续vim的发展也正是围绕着一群以提高编辑效率为目标的程序员之间展开的，
所以"上手容易"从来就不是vim的主要目标。时至今日，虽然vim也有了GUI版本，
但是除了多了一个简陋的标题栏和基本功能菜单外，主界面仍然是光秃秃的，与终端版本没什么区别。

那么问题来了，不容易上手，GUI版本又没改进，那vim好在哪？简而言之，
就是命令式交互的效率优势。

vim和常见的GUI文本编辑器之间的差异与优劣可以归结为
"命令式"与"图形界面"两种人机交互之间的差异优劣.

命令行要求输入明确(通常是键盘命令),固定的输入序列对应固定的功能行为。
不直观,上手困难。但只要你掌握了所用到的功能,就可以实现复杂的功能组合,(比如bash)。

图形界面的改进是：输入可以比较模糊（比如鼠标点在一个按钮的任何位置都可以生效）,
直观易懂上手容易，如果UI上提供了相应的功能，那么一键即可完成。如果UI没有提供相应的功能,
用户则无法使用程序内部功能的新组合。图形界面中的快捷键，则可视为
命令式输入的"固定的输入序列对应固定的功能行为"逻辑。

虽然在易用性，直观性上图形交互大大进步，但是在目的明确的操作中,
使用键盘进行命令式交互的效率要优于大量使用鼠标操作的图形化交互。
比如编辑器在菜单里都会提供复制粘贴按钮，但是大部分人都会用ctrl+c/ctrl+v。
再比如最常见的Home/End/PageUp/PageDown功能键，
这些都是用一个快捷键执行一个固定的命令的操作，并不需要GUI的视觉交互。
你可以按一个按钮达成目标，就没必要用菜单里一层一层的菜单项
（即使你要通过菜单项来使用程序功能，那用Alt菜单键的快捷操作，也要比通过鼠标点选更快更准确）。

想想你用鼠标怎么操作GUI?先用眼睛确认一下鼠标位置,再移动
到菜单上,可能还有二级菜单,再到按钮位置上,再点一下......哪能有效率。
鼠标更适合操作不明确的场合,比如photoshop里,画一个"硬币大小"的圆形，

命令式交互中，使用者在用更符合计算机的低级逻辑在思考（指定每一步的明确操作）
依靠的是使用者的记忆和固定的按键输入(一个熟练的bash使用者完全可以闭着眼睛
完成想要的操作，只要他别打错字)

图形化交互，则要依靠GUI开发者将程序功能组合成更直观的形态体现给使用者，
逻辑更高级，但是GUI（基于菜单，面板，按钮）难以克服的问题就是，GUI
开发者很难将所有的功能都通过可视化的形式表现出来。以文本编辑为例，GUI可以设计
"向下跳5行"的快捷按钮，但是不能把"向下跳1行"到"向下跳100行"全都设计成按钮
(当然你可以设计成跳转到xx行输入框，不过这就变成了键盘输入)。用户的使用场景
和需求是多变的，但GUI难以把每一项需求都用UI元素显示。即使都有对应的元素，
用户在使用中需要用眼睛检索UI元素（所以才是图形化嘛），增加的命中延迟会抵消直观
所带来的效率。

很不幸的是，在"意念输入"这种不着边的技术还没有实用化的时候，命令式输入是追求
极致效率时的必然选择。

看一看3dsmax/photoshop就可以体验到这种感觉：功能非常丰富，有一大堆菜单和按钮，
眼花缭乱。但是expert mode下就变成光秃秃的主视图，菜单什么的全没了,全靠熟练使用者
用快捷键完成(确定功能的操作全部用命令式进行操作)。这就像玩魔方，背复杂解法
当然很繁琐，但一旦记住，复原速度就比简单解法更快。

文本编辑的任何一项操作都是过程明确的操作,不存在"差不多"这种"语意模糊"的动作，
vim 即可比作文本编辑的"复杂解法"。对于大部分没有使用过vim的人而言，
Home/End/PageUp/PageDown，ctrl-c,ctrl-v,
ctrl-z,ctrl-shift-z再加上方向键就是全部的文本操作了，
但是在vim中，跳到n个单词后，删除n行,选中文本，回到上一处位置.....
等等等等你想得到的想不到的操作都有对应的命令，只要你有精力去学习更多命令，
编辑效率就能更高。另外vim的命令集中在住键盘区域，也可减少手指移动的距离。

总结下来,vim的难用,是以"图形界面人机交互"的标准来衡量的(直观和上手容易).以
"命令行人机交互"的角度来看,则当然是"好用"(灵活和效率)，也并不是IDE效率低下，而是
鼠标操作效率低下。

效率与取舍

IDE主要是特定语言开发的"整合",比如项目管理,编译调试,语义补全,
项目内搜索和跳转.等于"一个开发环境,内置比较弱的文本编辑器"。

相形之下vim则比较麻烦，诸多高效率的功能(比如IDE功能，语义补全功能)都要依靠插件，
学习这一大堆插件怎么用的好也要费时间。等于"一个文本编辑器,外带繁琐的优化配置和
比较弱的开发环境"

因此你的选择也就变成了:选择整合环境的快捷,还是选择文本编辑器的强大

什么时候考虑尝试？很多人在语言学习的初期都会选择IDE快速上手,但随着代码越写越多,IDE的功能也
都可以用快捷键来完成的时候,那就是时候去尝试一下vim了.写代码说到底还是编辑文本,
依靠命令式操作以提升文本编辑效率，是提升整个工作效率最后的，也是最重要的一部分。
即使尝试过之后最后觉得还没有IDE的效率高,最终选择用IDE,这种尝试也是值得的。

究竟要不要切换？看看你80%时间里操作的功能,是IDE强,还是vim强。

考虑下IDE哪些部分比vim强（只是随便想到的，不全面）
"goto everything",打开一个即时搜索框,模糊匹配用户输入的任意内容,可以是文件名,
也可以是类名或者方法名,变量名(everything嘛).这个是IDE整合功能比较强大的地方.
另外语义补全,语义重构,引用查找之类也都是IDE的强项.总之就是关系到"一些特定文件组成项目"这个概念
的功能,IDE更优胜。

决定尝试vim,如何学习？学习vim最关键的两点:
一曰吃饱了撑的闲出个屁来:有时间来实战练习，靠身体实践来记住操作(你按ctrl-c的时候用大脑吗?)
二曰一颗耐操的心:练了两天忘了一大半,结果还比不上notepad快...

这玩意也像玩魔方,练的久自然快。每天操作一点点,两个礼拜之后文本
编辑效率超notepad应该没问题.如果你觉得vim在文本编辑上确实比IDE方便,
那接下来要考虑的问题就是,如果迁移到vim,IDE方便的功能怎么替代?

答案是:一切皆文本,用文本代替(有没有一点unix一切皆文件的意思?).

vim是强大的文本编辑器,只要一个概念用文本的形式展现出来的时候,
你日常的文本操作流程，则完全适用于同样是文本的这个概念。比如IDE集成的文件系统浏览,
在vim的NERDTree插件里就把文件名列举在一个文本里,
文件名上回车,就是打开这个文件.有够简陋吧?但是换一个角度想，所有的文本操作也一样可以应用在文件名列表上,
比如选中第10个文件就是跳转到第10行的文本操作，搜索制定文件名文件,也就变成了简单的
搜索匹配文本,复制文件名就是复制一段文本......是不是有够强大呢?
IDE集成的文件管理控件不也就是一个个文件名排列而成吗?只不过和vim画出来的样子不一样罢了。

vim有很多模拟IDE的插件，作为一个日常使用vim做C/C++开发的使用者，我觉得这些插件
在整合方面还是比不上IDE的，但我一天80%时间里的操作用的都是vim比IDE更便利的部分，
毕竟写代码还是编辑文本嘛。所以依然选择用vim。至于那些不如IDE的，暂且忍了。

强强联合现在IDE集成的文本编辑命令也很丰富(不过我没时间去一个个尝试了），有的直接提供vim操作绑定，可模拟vim常见的基本操作，再配合IDE本来的长项，确实是如虎添翼。比如eclipse配上vrapper (vim绑定)再加上合适的补全配置，那java简直是一路按回车写完代码。当然也有eclim这样反过来的，vim是主界面，后台调eclipse的项目管理和补全功能。总之一点：vim专注文本编辑十几年，毕竟是有两把刷子的， IDE专注整合，也不是吃干饭的。现在一个新项目neovim 也开始了，将核心功能剥离成可嵌入程序使用的库，也许以后我们会见到很多IDE,在文本编辑区完美整合一个全功能的 vim 编辑器。单纯讨论谁更优秀没有意义，只有你亲身体验过两种，才能给出适合你自己的答案

其他杂谈：

很多网友提到开发机要ssh上去远程操作不得不用vim,如果非要用IDE,那么IDE集成的sftp
功能可以直接编辑远程主机文件，也可以靠sshfs(windows上也可以！)直接挂载远程主机的文件系统，
令任何编辑器都可以透明编辑远程主机文件。

很多用虚拟机学Linux 的人都抱怨虚拟机慢，可能是配置不当。近两年的cpu(甚至早到
intel core2 T8300那样老的cpu)都支持硬件虚拟化指令集(amd查是否支持svm,intel查是否支持vt-x)，
bios里打开这个配置，虚拟机的cpu性能不会差很多的。性能瓶颈主要是虚拟磁盘的IO.
如果你愿意折腾，可以,把主机的磁盘直通(virtualbox和vmware都支持)给虚拟机器用。
保险起见可以在windows下给linux分区(但不格式化)，安装linux时候格
式化准备好的分区即可。要点是不要将grub安装在mbr(或者efi模式下不要改写主机的esp分区)
win7/8系统可能对这个启动关键区域施加了额外保护，会导致虚拟机操作失败。这样安装
后的虚拟机Linux,其实已经完全安装在了物理硬盘的真实分区上，可以在物理主机上正常使用
(当然你要在物理主机上修复一下启动项，比如修复grub什么的)。这样操作之后，你可以
在Windows下用虚拟机来运行这个linux 先学习学习，也可以在熟练后让物理主机直接启动
到这个Linux 里面进行操作。

关于AST IDE.这个是 @jianghu52 推荐的一篇博文中提到的，就是语意编程，用AST元素
（而非解析前的源码文本）作为编程输入的基本元素，这一类IDE或可改进源码的可读性
和可重构性，但我对AST IDE的输入效率表示怀疑，问题在于，AST IDE怎么把程序逻辑
展示给编程者？怎么输入基本元素？如果用UI，那我是否要用拖动的形式来输入？如果是
文本输入，那与文本编辑的区别与优势在哪？虽然AST相比文本是更高级的思考形式，但我觉得
文本操作的便利灵活这个优势在很长时间内是难以超越的。假如意念输入真能成为现实，
或许我们可以省略掉脑中AST->文本->语言AST这个步骤。这也不算异想天开，科技的进步谁又说的准呢。

做个烂广告：
nano75s,一款低价的国产机械键盘，然而这货有一个杀手应用：键盘模拟全鼠标操作
包括移动，点击，滚轮，调整dpi,外加全键位可重新映射，
是吊丝打造全自定义键位的不二选择(全开源可自定义的GH60可不便宜啊)
.有兴趣的可以去尝试一下，看看全靠键盘的操作，究竟是什么感受（打游戏被队友爆菊不要来找我）