Emacs作为编程环境的不足

写了一段时间的程序，感受过各种编程环境，也数次学习Emacs（或者Vi）并期望这两者能搞定大部分事情。不过，最后还是发现术业有专攻，作为编程环境的时候，某些情景这哥俩还真的不怎么适合，姑且称为不足吧，记录在这里。
这里马上想说的是，我不是Emacs和Vi的粉丝，但是很喜欢两者的某些设计和功能。努力学习过他们，在生产环境中也经常用到，但并不精通。如果有我不知道或者说错的地方，敬请批评指正。另外，这贴无意于讨论IDE还是Notepad写程序谁更高明的问题。
1、项目的组织方式
Emacs首先是作为编辑器而存在而出名（我想Vi也一样），在不用插件时，它面向的是单个文件，若考虑split和tab方式，则是面向多个单独的文件。当使用了某些插件以后，它可以“看到”并“管理”目录树，部分变成了面向目录的管理方式。无论是面向文件的还是面向目录树的，Emacs都首先致力于对于单个文件内部编辑功能的强大。项目所用到文件之间的关联，在编译之前关联是松散的——Emacs把它们当做单独的一个一个文件，至多是以文件系统的目录树结构组织。这有的时候很好，确实符合KISS和工具高内聚低耦合的思路：通过文件系统组织项目，通过shell直接实现文件的操作以实现项目的管理。而现代的IDE基本都是面对“项目”这个概念。Emacs这种面向文件的方式，相对就有些不足：：

• 调整项目的目录结构，Emacs靠的是命令，文件一多效率就可想而知；（不过这一点是典型的鼠标操作优势项目，有点作弊的嫌疑）
  
• 依据当前符号在项目内跳转，比如点击函数定义，直接跳转到函数体，Emacs对C还支持，对其他语言就。。。；
  
• 查找类的继承结构时，IDE会在项目中找到相应的符号并跳转。Emacs并没有“项目”这个视野，跳转或者类的继承结构有可能不完整；
  
• 项目文件数目和种类都较多，并且分布在不同目录中时。这种情况下IDE一般会把文件按类型分门别类列好，也就是说，导航栏强大的多；
  
• IDE会根据对项目的操作（添加文件、删除文件、改名、改目录）自动变更项目文件或者Build脚本，而Emacs需要在做了这些变更以后，再慢慢到脚本里找到相应位置进行更行；
  

想象一个极端场景吧，一个项目拥有100个文件，其中80个代码文件，放在一个目录中（叙述简单起见）。由于重构的需要，我们需要调整目录结构，根据命名空间将他们分门别类放进相应的目录，这些文件有若干个类，有几个类方法很多，参数复杂，类继承系统也超过3层。这种场景现代IDE相对能较快速的解决问题，这个时候Emacs搞不好还在来回翻查目录移动源代码或者是同步Build脚本。
尤其是现在大家都在写着“胶水”代码，更注重“结构”而不会在一个文件中死磕很久（我相信做算法的牛人或许不是这样），Emacs的优势在弱化，而对于项目管理的劣势就更明显。前两天还看了篇文章说程序员真正在“写”程序的时间不会超过50%呢。
2、缺失的功能和黑客的插件
Emacs和Vi本身在文字处理方面的功能非常强大（低耦合高内聚嘛），由于某些非文字编辑功能的缺失而且系统又比较开放，各种插件层出不穷。可以说，没这些插件真就没有Emacs作作为编程环境的今天（其实裸奔Emacs对编程支持得还算友好啦，Vi裸奔基本什么都没有么），什么Colortheme，numberline，etags，CEDET，cscope等等等等的插件大大增强了Emacs在程序开发方面的能力（甚至有部分弥补了上面第一部分我说的不足）。相应的，Vi也有许许多多各种各样的插件（比如上推特啦，收邮件啦，聊Gtalk啦-_-）。但是，但是！这些插件有着相当浓厚的黑客味道：
<ul>配置插件配置到你崩溃，不断改配置，重试，改配置，重试，直到你的Emacs再也起不来鸟~~~>_