Editors


配置Emacs为C/C++开发环境:安装配置cedet

Table of Contents 犯罪动机 源代码下载 编译cedet 配置 替换内置的cedet 其他的配置 安装配置ecb 使用过程中遇到的问题 鼠标,又见鼠标 犯罪动机 刚开始使用Emacs时,也有找过cedet的相关资料,只是当时还不怎么用Emacs来写C/C++代码,所以只是浅尝辄止,也可以说几乎就没弄。渐渐熟悉了Emacs,在上面写代码的频率也高了,于是又重新拾起cedet。 由于使用的是Emacs24,里面已经自带了cedet,起初认为自带了更好,不用折腾。等到真正查资料要配置时,才发现根本不是那么回事。比如网上配置cedet的帖子中,常常会提到semantic-load-enable-minimum-features等设置函数,可是无论我怎么搞(加require ‘cedet,加semantic/canned-configs等),就是不行,一直出错。实在不行了,就跑到/usr/local/share/emacs/(我是用brew装的Emacs)下用find命令去抓semantic-load-enable-minimum-features这个串,结果还是没抓着,于是确定是Emacs内置的cedet并不包含这部分实现。起初还以为是OSX下的Emacs的问题,后来跑到Ubuntu下试,一样一样的!于是找啊找啊,总算找到为什么:semantic-load-enable-minimum-features这种设置方式,不符合minor-mode的规范,因此去掉了。邮件中还提到其他的几点改动,包括部分去除调试功能,使用的cedet版本较老等。 考虑了一下,还是觉得内置的版本不爽,于是决定折腾折腾自己,到官网上下载来编译安装。 源代码下载 这个很简单,Google一下,马上知道。到cedet的官网源码下载页上找到下载地址,使用bzr或者git下载即可: bzr checkout bzr://cedet.bzr.sourceforge.net/bzrroot/cedet/code/trunk cedet 为了方便,我在.emacs.d中建了一个3rd-party的文件夹,将cedet的源码直接下载到了这个目录下。 编译cedet 编译过程相对简单,也很顺利: # cd cedet make EMACS=/usr/local/bin/emacs-24.3 # optional to compile cedet/contrib: cd contirb make EMACS=/usr/local/bin/emacs-24.3 上面脚本首先进入cedet目录中编译cedet的标准模块,而后(可选)进入contrib子目录,编译其他不符合FSF协议的模块。 配置 替换内置的cedet 由于Emacs24内置了cedet,因此要尽早载入外部的版本(比如在.emacs的开头),避免由于Emacs已载入内置的eieio(cedet中的基础模块)而导致我们的cedet无法载入的问题。 ;; load cedet. It is very […]


配置Emacs为C/C++开发环境:识别不同文件夹中的头文件

作为一个不折不扣的码农,Emacs最重要的功能就是要能够帮助我提升写代码的效率,其中我认为很重要的功能有两个,一个是代码补全,另一个则是语法检查。对于代码补全,我使用的是auto-complete配合auto-complete-clang-async;而语法检查使用的是flycheck配合clang,用起来很爽。刚开始写一些小的C/C++程序,头文件和源文件都是放在同一级目录下的,这种情况下auto-complete-clang-async和flycheck工作得都很好。但是好景不长,项目一旦稍微复杂起来,就会分不同的目录,而包含的头文件总不可避免地会在不同目录下,结果由于找不到头文件,导致auto-complete-clang-async和flycheck双双失效了:由于头文件都是放在文件最开始的,由于没有指定头文件所在的路径,clang解析include指令时会因找不到文件而出错,停止解析。这样,后续源码中如果出现其他错误,或者需要自动补全时,就不会有任何提示了,Emacs几乎退化成了一个普通的代码编辑器了! Google了好长时间,刚开始还寄希望于cedet和ede之类的,始终没有结论,没法解决这个问题。后来,极度郁闷中时,峰回路转,脑子终于开了点窍:我在意的压根不在于项目管理,而在于补全和语法检查功能。而且Emacs中各个扩展大都是各自为战的,即便搞定了项目管理的配置,也极有可能搞不定这两个核心功能! 于是屁颠屁颠回到原点,重新查找auto-complete-clang-async和flycheck中关于头文件的配置。明确了目标和方向,很快就有了眉目: 在flycheck中,可以通过flycheck-clang-include-path来添加/指定要搜索的头文件路径 在auto-complete-clang-async中,可以通过设置ac-clang-cflags来添加头文件路径 思路有了,那么具体的设置方法呢?别急,我一一道来(假设头文件路径为./include): 直接设置法:打开要编辑的源文件,然后执行M-x eval-expression,之后在mini-buffer中输入(add-to-list ‘flycheck-clang-include-path “include”),然后再执行一次eval-expression,执行(add-to-list ‘ac-clang-cflags “-Iinclude”)。如果还有其他的路径,则重复以上操作,一个一个添加进去。另外,由于这两个变量都是局部于文件的(即仅对当前buffer有效),因此当打开一个新文件时,还得重新设置。 上面的方法实在是太烦了,是地球人都受不了。为了偷懒,我决定写一点程序,在打开一个C文件时,自动判断是否存在./include,../include,./inc或者../inc目录,如果存在,就将他们添加到ac-clang-cflags和flycheck-clang-include-path中。这种实现简单粗犷,但基本满足我的需求: ;; detect and add headers path, to make flycheck and clang-complete work ; make sure flycheck-mode is enabled (global-flycheck-mode) (defun check-and-add-header-path (checkpath) “Check if CHECKPATH exists and it’s a directory, if it is a directory, then and […]


Emacs中编辑保存makefile文件时会错误地将TAB转成空格的解决方法

问题描述 我的Emacs使用了Purcell的配置,在其配置中使用了whitespace-cleanup,且通过在.emacs.d/lisp/init-edit-utils.el中设定: (require ‘whitespace-cleanup-mode) (global-whitespace-cleanup-mode t) 这样设定后,默认会全局使用whitespace-cleanup-mode,导致的结果是在保存文件前将TAB转换成对应的空格。这样的结果在多数情况下是我们想要的,但是对于有些类型的文件(比如makefile)而言便是灾难了。通过实测发现,只有当新建maekfile文件保存时,才会将TAB符替换成空格,导致makefile格式错误,而打开编辑一个已存在的makefile后保存则不存在这个问题。 解决方法   网上的方案 网上查了很多资料,基本都是以下解决方案: ;; 默认不加载indent-tabs-mode (setq-default indent-tabs-mode nil) ;; 保存文件前执行一次whitespace-cleanup (add-hook ‘before-save-hook ‘whitespace-cleanup) ;; 如果是打开makefile文件,则开启indent-tabs-mode,因为whitespace-cleanup中会用到这个 (add-hook ‘makefile-mode-hook ‘indent-tabs-mode) 但是我看了Purcell配置,发现两点跟以上解决方案不符: Purcell的配置并不是使用after-save-hook的,而是启用global-whitespace-cleanup-mode来实现空格处理的功能 当前版本的whitespace-cleanup-mode的实现代码中,并没用使用indent-tabs-mode,因此修改这个没用 我的解决方案 经过一系列的失败尝试后,我总算找到一种解决方案: ;; 后面设置tab-width部分只是个人喜好,与本问题无关 ;; 当打开makefile文件时,禁用whitespace-cleanup-mode。其他类似需要保留TAB的文件类型也可以采用这种方法 (add-hook ‘makefile-mode-hook (lambda () (whitespace-cleanup-mode 0) (setq tab-width 8))) 现在,我们在Emacs中新建makefile文件并保存后,再也不会出现问题了!^_^ Author: Rex Shen Created: 2014-03-05 […]


Emacs及扩展配置

Table of Contents 动机之反思 它山之石 扩展的管理 我额外安装的通用扩展(在purcell基础上) LaTex相关的问题和配置 org模式相关的问题、扩展及配置 (K)Ubuntu英文环境下Emacs配置中文输入法 其他遇到的问题及解决 总结 动机之反思 捣鼓了几天,总算把Emacs配置到基本正常使用的程度了。虽然有点迟,但还是尽量将能想起的细节都记录下来吧,否则以后要用到时都忘光了。 为什么会想转到Emacs上呢?多年以前,当我还在读大学时,就玩过Emacs,但是可能是觉得操作不方便,也可能是身边有朋友在用Vim了,捣鼓了一小段时间Emacs后,就转投向学习使用Vim了。 其实Vim作为编辑器而言非常好用,但是作为开发IDE而言,总是感觉欠缺;之前看过别人用Emacs,确实在代码调试上有其优势,可能就是因为这一点,一直耿耿于怀吧。 另外,在很早之前我就觉得在Emacs中显示中文很漂亮,比Vim中显示要漂亮些。恰好这次新买了MBP,换了OSX系统,就想在上面全新配置自己的环境。加上自己有一些任务管理、使用LaTex等的需求, 上网一搜,全都是将在Emacs上怎么实现的,于是就心痒痒想试试了。 本来想完全抛弃原先Vim的使用习惯,重新学习Emacs的各种操作的,但是每次用到Emacs那些复杂而且别扭的快捷键时,总是由心地希望用回Vim。我想,这就是Vim阵营的人鄙视Emacs的一大原因吧。 好在作为独缺好编辑器的操作系统,Emacs开发者已经为我这种两面派提供了终极解决方案:各种模仿Vi操作的扩展。最终,我使用了Evil,将ELPA中所有Evil开头的扩展都装了个遍,并将Emacs设 置为默认进入Evil模式,重启生效,顿时世界一片清静。其实我不太能理解为什么网上会有这么多Vim和Emacs之争,为什么不能站在相互取长补短的角度来使用它们?我觉得,只有真正去用一个工具, 才能真切体会它的好;同样,只有真正了解对手,才能发现自身的不足,也才有动力和方向去进一步完善它。当然,我只是一个纯粹的实用主义者,谁能解决我的问题,予我方便,我就用哪个,如果中 间遇到什么现在还没有的功能,而我有恰好有兴趣和时间去完善,那我才会去完善,回馈相应社区。 我不知道这次用Emacs会坚持多久,或者用了一段时间后发现不习惯了,还是用回Vim了。不过自从用了Evil,我感觉还是挺顺手了,现在环境也配置得七七八八了,应该够我用一阵的了。后续如果再 遇到问题,如果有时间,我想我还是会在Emacs上折腾的。 它山之石 刚开始我是从零开始配置Emacs的,所有的配置都写在~/.emacs中,基本也能工作,就是感觉自己要配置的东西太多,太繁琐。google了一番后,找到这篇文章:一年成为Emacs高手(像神一样使用编辑器), 里面的介绍蛮好的,作者力荐学Emacs要从使用研究大牛的配置开始,我刚刚开始学,不知道这样是否是最佳的学习方式,因此持谨慎的保留态度,但不可否认的是,大牛们的配置确实让我们省去了很多繁琐, 并且,给我们的后续配置提供了一个不同于原始Emacs配置方式的扩展框架(缺点是我们必须先搞清楚大牛的框架,否则出现问题时就不知道怎么办了)。老实说,相比Vim大牛们的配置,在网上能找到的 Emacs配置还是有点弱的,很多功能都没有,特别是编程方面的,基本就没有(purcell和prelude配置中对于C系的自动补全和自动缩进等都没有配置)。 从我google的结果来看,比较普遍使用的Emacs配置集基本有几个:purcell、prelude以及emacs-starter-kit。(注意,如果使用这些配置集,就不能添加自己的.emacs文件了,否则会导致这些配置集 失效;这些配置集内部都有机制可以让你定制自己的功能的) starter-kit:由于starter-kit的名字表明我太初级了,而我又自命不凡地觉得自己用了那么多年的Vim,不应该属于初级那类,因此我始终没有用starter-kit,也就无从知道它好不好用了。 purcell:purcell是《一年成为Emacs高手》中推荐的,作者Purcell本身是从事Web开发的,从评论上看更新有点快,所以自己配置的话,可能经常会出现配置冲突。这个配置中有个比较好的功能, 就是可以保存桌面,保存的桌面可以在下一次打开时自动载入。purcell的版本默认装不了el-get,因为跟装在里面的scratch扩展有冲突,我的解决方案是在git clone el-get的过程中在终端通过 sed命令将el-get中冲突的部分替换掉,或者启动Emacs后,先将scratch卸载(在ELPA中卸载),然后执行el-get的下载脚本,安装成功后再重启Emacs;由于启动时purcell配置会自动检测更新配 置环境,因此在启动过程中会检测到scratch被删除,然后重新下载安装scratch。在purcell中,如果要加入自己的定制,则可以通过在Emacs中执行“M-x customize-variable”或者在 ~/.emacs.d/lisp/中增加init-local.el文件,这个文件相当于.emacs文件,只是记得文件最后要有一句: (provide ‘init-local) prelude:在网上乱搜的时候无意看到这个的,后来发现其实很多人都有推荐这个,比推荐purcell的多。它设置了一个较好的功能,就是保存“el”文件时自动编译。如果要添加自己的东西,则可以同样 通过“M-x customize-variable”,或者:在~/.emacs.d/personal/中添加后缀为“el”的文件,这样prelude便会自动载入这些配置了,这点感觉比purcell的实现要灵活一些。我大概花了一天左右的 时间在prelude上安装扩展和配置,弄得七七八八,基本能正常写代码了。不过后来头脑一热,又改成使用purcell了。现在回过头来看,purcell和prelude相比,并没有太多的孰优孰劣,要改成自己习 惯得折腾一番,所以选择哪个完全是自己喜好了。 扩展的管理 目前Emacs主要有两种扩展管理器,一个是ELPA(package.el),另一个是el-get。其中ELPA是从Emacs24版本开始内置到Emacs中的,是官方的扩展管理器,但其仓库中的扩展比较少,需要配置其他仓库; […]