豪士君测试所用平台

以下就是我们整理的Emacs作为IDE编程环境的不足，一起来看看，希望能帮助到您。

写了一段时间的程序，感受过各种编程环境，也数次学习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啦-_-）。但是，但是！这些插件有着相当浓厚的黑客味道：配置插件配置到你崩溃，不断改配置，重试，改配置，重试，直到你的Emacs再也起不来鸟~~~>__<~~~ 除了几个著名插件，其他插件的完成度真的比较让人怀疑，兴趣爱好么，写到一半没兴趣了怎么办？讲与时俱进讲了这么久了，插件还真是做不到与时俱进那。 C和C++加上插件基本成套能用，其他语言那？记得有一次，一个html/css/js的项目写到一半，突发奇想用了一会儿vim+网上大牛推荐的几个著名插件，哎呦我的妈，这是回到了侏罗纪吗？基本的代码着色，代码缩进还能做的更差一点吗？ 当然，随着插件的完善，Emacs和Vim还是有更完美的希望的。也许什么时候Netbeans Eclipse这些都被干翻了，IBM和Oracle回到Emacs或者Vi怀抱，又或者Google被弄得没ide用了，这时候Emacs和Vim插件就有希望了。也就是说，Emacs作为开发环境缺乏大厂的支持，这是它的一个硬伤。3、高级特性下面这些高级特性上，Emacs和Vim的差距也比较大：首先要说的高级特性就是智能感知和补全，在微软叫Intellisense，在其他的厂，好吧，就叫Auto-Complete… 这个差距就大了去了。基本上Emacs在C和C++领域还能撑一下，只能说略输现代IDE一点，基于项目和语法分析的插件勉强赶上时代（勉强比Eclipse，Netbeans这种差一点，和VC和SlickEdit比那就是厕所里点灯）。其他语言的智能感知和补全基本上就是农业社会了——基本上就是基于单词表的，囧。其实Emacs也做得出来，不过这种东西没大厂雇一帮人，做个能用的蛮难。 其次是重构啊，单元测试啊，源代码管理啊这些热点特性基本也没戏了，Emacs里只能Shell开起来，小碎步抖起来了。 再然后是调试的支持。Emacs也好Vi也好，插件一个不落全装上，对GDB支持还是蛮好的。即使这样，GDB目前看起来调试功能和Visual Studio还是有一定差距（举个例子，VS好几年前开始支持泛型容器直接看内容了，可能我土鳖，不知道GDB也支持了）。然后，其他语言的调试，又是一片悲剧，插件又没跟上！ 最后再提一小点：对于类库、框架、插件的管理和支持。Eclipse，Netbeans，VisualStudio都有比较完善的插件管理机制，你要哪些插件，随你选，然后自动下载安装搞定。Emacs和Vi满世界找插件，下载以后改配置文件，没配置对还要悲剧。现代IDE对于某些程序需要的类库框架也是这种管理方式，搜索，下载，直接加入项目文件或者build文件，然后对于框架有较多的自动生成功能（比TextMate的Bundles高档多了，基于语法分析的一般）。不过说实话，这点写成Emacs的缺点还真有点心虚，因为这本来就是集市和大教堂的区别。 总的来说，比较根本的缺点其实只有两个：面向文件而不是面向工程的管理方式；没有大厂支持。前者是由于Emacs（Vi）编辑器的本质造成的，后者，额，我也不知道是什么造成的。洋洋洒洒写了这么多，其实我还是挺喜欢Emacs也挺喜欢Vi的，他俩最吸引我的其实还是全键盘的操作方式——相当的装B啊，给别人演示的时候倍儿有面子——还有就是奇快的速度，拿来做一些小项目速度很快也很顺手。但是挨踢界确实也是一日千里，Emacs和Vi能迎头赶上就好。Emacs本身定位上可能就不是代码编辑器,至少流行的没见过哪个在文字窗口显示图片的,不过这也有个好处就是会有一些支持latex预览的插件VI/Emacs是顶级高手用来开发操作系统，数据库，编译器，新的编程语言等等，你说NB吗？当然这种东西最好是有高手带，因为学习曲线非常的陡。VS2010确实很好，要是再稳定点就更好了。Emacs和VI也有他们的好处，也有些文章介绍的。我觉得最牛逼的地方是这两个东西可以完全脱离鼠标。

关于Emacs作为IDE编程环境的不足的内容到此结束，希望对大家有所帮助。豪仕知识网往后会继续推荐Emacs作为IDE编程环境的不足相关内容。