Emacs作为编程环境有哪些明显的缺陷？

本文共计2032个文字，预计阅读时间需要9分钟。

写了一段时间的程序，感受到各种编程环境的差异，也多次学习Emacs（或Vi）并希望掌握大部分事情。不过，最后还是发现，对某个领域有专攻，作为编程环境使用时，某些情境下，这位兄弟还是挺真的。

写了一段时间的程序，感受过各种编程环境，也数次学习Emacs（或者Vi）并期望这两者能搞定大部分事情。不过，最后还是发现术业有专攻，作为编程环境的时候，某些情景这哥俩还真的不怎么适合，姑且称为不足吧，记录在这里。

这里马上想说的是，我不是Emacs和Vi的粉丝，但是很喜欢两者的某些设计和功能。努力学习过他们，在生产环境中也经常用到，但并不精通。如果有我不知道或者说错的地方，敬请批评指正。另外，这贴无意于讨论IDE还是Notepad写程序谁更高明的问题。

1、项目的组织方式

Emacs首先是作为编辑器而存在而出名（我想Vi也一样），在不用插件时，它面向的是单个文件，若考虑split和tab方式，则是面向多个单独的文件。当使用了某些插件以后，它可以“看到”并“管理”目录树，部分变成了面向目录的管理方式。无论是面向文件的还是面向目录树的，Emacs都首先致力于对于单个文件内部编辑功能的强大。项目所用到文件之间的关联，在编译之前关联是松散的——Emacs把它们当做单独的一个一个文件，至多是以文件系统的目录树结构组织。这有的时候很好，确实符合KISS和工具高内聚低耦合的思路：通过文件系统组织项目，通过shell直接实现文件的操作以实现项目的管理。而现代的IDE基本都是面对“项目”这个概念。