你可以点此下载Easwy的vimrc，如果你了解git，你也可以使用git命令下载整个版本历史：

git clone https://github.com/easwy/share.git

用这种方式，你可以随时跟踪我的最新修改，或者把你对vimrc的改变通知我。

Happy Vimming!

文章的脚注信息由WordPress的wp-posturl插件自动生成

目前最新的vim版本是7.3，因为从vim 7.3开始已经换用Mercurial做为版本管理工具，我们在下载vim 7.3源代码前，先要安装Mercurial:

sudo aptitude install mercurial
cd ~
hg clone https://vim.googlecode.com/hg/ vim73

执行完上面的命令后，我们就取得了vim 7.3的最新代码，放在目录~/vim73中，接下来准备编译。在编译前，需要安装编译时需要的包，在Ubuntu上用如下命令：

sudo aptitude install xorg-dev libx11-dev libgtk2.0-dev libncurses5-dev 

上面是Easwy在编译前所安装的依赖文件。后来在一篇帖子中看到另一种方法安装依赖文件，可能更方便(未测试)：

sudo aptitude install build-essential
sudo aptitude build-dep vim-gtk 

接下来修改~/vim73/src/Makefile，打开自己所需要的功能，Easwy打开了下面这些特性：

接下来编译安装：

cd ~/vim73/src
make && make install 

执行完后编译好的vim以及gvim就安装在/usr/local/bin目录中了。将此目录加入PATH即可。

Easwy在编译后，每次运行gvim都会提示：

Warning: Missing charsets in String to FontSet conversion
Warning: Unable to load any usable fontset
Warning: Missing charsets in String to FontSet conversion
Warning: Unable to load any usable fontset
Error: Aborting: no fontset found 

后来在网上查了一下，是因为没有安装libgtk2.0-dev包造成后，安装此包再重新编译后问题解决。

如果你在编译gvim时遇到了问题，可以参考我以前写的一篇文章：vi/vim使用进阶: vim编译中遇到的问题及解决方法。

最后，把我们编译的vim 7.3做为Ubuntu中的缺省编辑器，执行如下命令：

sudo update-alternatives --install /usr/bin/editor editor /usr/local/bin/vim 50 --slave /usr/share/man/man1/editor.1.gz editor.1.gz /usr/local/man/man1/vim.1.gz
sudo update-alternatives --install /usr/bin/vi vi /usr/local/bin/vim 50 --slave /usr/share/man/man1/vi.1.gz vi.1.gz /usr/local/man/man1/vim.1.gz 

Happy viming!

更多内容，请阅读易水博客上的其它文章。

[ 参考文档 ]

文章的脚注信息由WordPress的wp-posturl插件自动生成

不过Easwy在这里要介绍是在Linux下使用Vi来完成改名，实际上也非常容易。Easwy使用的命令如下：

vim `egrep -rl 'AAA|CCC' * |grep -v .svn`
:argdo %s/AAA/BBB/ge | %s/CCC/DDD/ge | w

第一条命令是一个Shell命令，这条命令使用Vi打开当前目录下所有包含AAA或CCC宏的文件。其中egrep查找所有包含AAA和CCC的文件，然后使用带”-v“参数的grep把位于版本控制目录中的文件过滤掉。最后，egrep所找到的文件做为Vim的命令行参数传入。

第二条命令是Vi命令，这条命令把上述文件中所有的AAA替换为BBB，把CCC替换为DDD，并保存文件。想读懂这条Vi命令，请阅读手册”:help argdo”

当然，在要修改的文件数目非常多时，最好使用sed之类的流编辑器，此时使用Vim效率会比较低。

更多关于Vim的内容，请关注易水博客上的其它文章。

文章的脚注信息由WordPress的wp-posturl插件自动生成

你可以在这里下载到文章中Easwy用到的所有文件：点此下载

更多内容，请阅读易水博客上的其它文章。

参考文档

文章的脚注信息由WordPress的wp-posturl插件自动生成

vim 7.3的功能需求还没有最后确定，Bram会根据自己能投入的时间和用户对vim新功能的投票结果来做最终决定。另外，Bram也在收集来自用户的patch和runtime文件。

Bram已经表示会增强Windows的安装程序，去掉lang和extra包。版本管理会采用Mercurial (在网上搜了一下，是一个基于Python的版本管理系统)。

vim注册用户赶快为自己期望的新功能去投票吧。未注册的vim用户需要交纳至少10欧元的注册费，然后到vim.org上激活自己的帐号。如果你在vim.org还没有帐号，可以在这里注册一个：http://www.vim.org/account/register.php。

文章的脚注信息由WordPress的wp-posturl插件自动生成

D:\Temp> cscope -Rbkq
Input file specified two times.

cscope: cannot create inverted index; ignoring -q option
cscope: removed files ncscope.in.out and ncscope.po.out 

当时Easwy以为是windows版本的cscope不支持-q选项。

不过网友Liang Feng昨天留言说：

Windows版本的cscope是支持-q选项的，出现以上错误是因为没找到合适的sort命令。所以只要cscope进程的工作目录下有GNU版本的sort就可以了。注意是进程的工作目录，不是可执行程序的目录。具体原因看一下cscope的代码片段。

build.c

#ifdef WIN32
snprintf(sortcommand, sizeof(sortcommand), “set LC_ALL=C && sort -T %s %s”, tmpdir, temp1);
#else
snprintf(sortcommand, sizeof(sortcommand), “env LC_ALL=C sort -T %s %s”, tmpdir, temp1);
#endif 

于是重新做了一下试验。在安装了Cygwin后，在cygwin的shell界面中使用cscope，没有出现上面的错误提示。但如果打开windows的命令行窗口cmd.exe，在里面执行cscope，则会出现上面的错误。

在仔细比较了cygwin和cmd.exe的环境后发现，原来是Windows自带的sort.exe搞的鬼。

在cygwin的shell窗口中，PATH环境变量的设置会使其先找到GNU版的sort.exe，所以上述cscope命令执行可以成功。但在cmd.exe窗口中，PATH环境变量会使其先找到windows自带的sort.exe而不是GNU sort.exe，所以会出现上面的错误提示。

知道了问题的原因，解决方法就很简单了，我们可以写一个批处理程序，在此程序中重设PATH环境变量，使cscope使用GNU版的sort.exe。示例程序如下：

D:\Temp> type cs.bat
@echo off
set path=c:\cygwin\bin;
cscope -Rbkq 

在这个批处理里，首先把path环境变量指向c:\cygwin\bin;，我的cscope.exe和GNU版的sort.exe都在此目录中。接下来现执行cscope命令，现在它使用的就是GNU版的sort.exe了。

在此感谢网友Liang Feng，谢谢他的提醒。

更多内容，请阅读易水博客上的其它文章。

文章的脚注信息由WordPress的wp-posturl插件自动生成

当执行下面的命令时，输出如下：

:echo system(Tlist_Ctags_Cmd . ' --version')
connect: Connection refused 

正常情况下，这条命令应该会输出Taglist插件的版本号，但现在显示的却是connect: Connection refused。于是查看了一下Tlist_Ctags_Cmd变量的值：

:echo Tlist_Ctags_Cmd
"/usr/share/eclipse/eclim" -command taglist -c "/usr/bin/ctags" 

这才想起，Easwy前些天安装了Eclim，用来在vim中使用Eclipse的功能。Eclim的作者对ctags和Taglist进行了加强，并且把Tlist_Ctags_Cmd替换成了他自己的版本。所以如果不启动eclimd的话，就会出现上面的错误。

知道了问题的原因，解决起来就简单了。使用/usr/share/eclipse/eclimd启动了eclimd后，Taglist窗口就能够正常显示了。不过Easwy暂时不想使用eclim提供的Taglist功能，所以在~/.vimrc中增加了下面的配置：

let g:EclimTaglistEnabled=0 

这样设置后，再启动vim，使用又是官方版本的Taglist了。

更多内容，请阅读Easwy的博客上的其它文章。

文章的脚注信息由WordPress的wp-posturl插件自动生成

*** info [lib/liblow.c(329)]:
/dev/gpmctl: Interrupted system call
*** err [lib/liblow.c(336)]:
/dev/gpmctl: No such device or address
Vim: Caught deadly signal TERM
Vim: Finished.
Terminated 

在偶然中发现，使用putty登录这台服务器时，运行vi命令没有问题。因此怀疑和TERM环境变量的设置有关。检查putty中此环境变量：

$ echo $TERM
xterm 

而在vi没响应的终端里，TERM环境变量的值为：

$ echo $TERM
linux 

如果把TERM环境变量的值也改成xterm，那么vi可以正常启动。看来的确是TERM环境变量引起的这个问题。后来又发现，如果在linux screen中启动vim的话(此时TERM环境变量的值为screen)，vim也不能正常启动。

那么为什么TERM环境变量的取值会影响vim的启动呢？经过认真排查，终于把问题定位到vimrc中的一个设置上：

set mouse=a 

如果在.vimrc中设置了set mouse=a，那么在TERM环境变量为linux或screen的终端上，vi启动时就会没有反应；如果去掉这个设置，不管TERM环境变量的取值是什么，vi都能正常启动。

阅读了vim的帮助手册，手册中说，这个选项只在一些特定类型的终端上支持，比如xterm、使能了gpm的linux终端等。看来问题是出在gpm上，从上面vim被kill后的打印中也可以看出，是/dev/gpmctl设备无法访问导致vi失去反应的。

后来在vimrc中把set mouse=a一句去掉，vi终于正常了。如果有其它朋友也遇到类似的问题，不妨试一下上述解决方案。

更多关于vim的内容，请阅读Easwy的博客上的其它文章。

文章的脚注信息由WordPress的wp-posturl插件自动生成

在文章在vim中使用gdb调试 – vimgdb中我介绍了如何使用vimgdb补丁在vim/gvim中调试程序。后来陆续有一些读者反馈了他们在使用中遇到的问题。在本文中总结一下。

[ 问题一: 运行GDB命令时提示"unable to read from GDB pseudo tty"? ]

有读者在试图执行GDB命令时，出现上面的提示。

出现这个问题是由于没有正确设置gdbprg变量。使用下面的命令设置一下GDB程序的位置即可解决此问题：

:set gdbprg=/path/to/gdb 

请把上面的/path/to/gdb替换成你计算机中GDB程序所在的路径。你可以把这句话加到你的vimrc中，这样每次启动vi时会自动设置此变量。

[ 问题二： 提示"GDB busy: command discarded, please try again"? ]

当你的程序需要用scanf()或者getchar()这类函数读取用户输入时，你可能会看到过这样的提示：

出现这个提示，说明你的GDB正在等待用户输入，所以无法响应你所输入的其它GDB命令。

在使用vimgdb时，如果你的程序需要读取用户输入，你必须通过GDB的tty命令或run来重定向程序的标准输入。

首先，你打开一个终端(可以是xterm/rxvt/urxvt/putty/…)，在此终端内输入命令tty：

$ tty
/dev/pts/17 

这条命令用来显示此终端所使用的设备文件名。获得了这个设备文件名后，你就可以重定向程序的标准输入输出到这个终端，在GDB中输入下面的命令：

tty /dev/pts/17 

执行完这条命令后，程序的标准输入/输出就被重定向到/dev/pts/17了，这样，当执行到scanf()或getchar()函数时，切换到那个终端输入指定参数，然后回车，程序就会继续向下执行。

[ 问题三： vimgdb可以在windows下使用吗? ]

vimgdb不能在windows下使用。不过你可以用作者提供的Clewn或Pyclewn。这两个程序可以在Windows的Vim/Gvim中使用。

这里有我写的一篇关于pyclewn的教程:在VIM中使用GDB调试 – pyclewn，clewn的用法与之类似。

[ 问题四： 按空格后vimgdb的命令窗口没有弹出来? ]

首先确保vimgdb的按键定义文件存在。执行下面的命令：

:set runtimepath?  

检查这条命令所列出的所有目录，如果任一目录中包含macros/gdb_mappings.vim文件，说明你的按键映射文件已经存在。如果你没有找到该文件，到vimgdb目录中找到这个命令，拷贝到上述任意一个目录中。

接下来用下面的命令加载vimgdb的键绑定：

:run macros/gdb_mappings.vim 

现在，你应该可以使用vimgdb所定义的快捷键了。

[参考文档]

<< 返回vim使用进阶: 目录

文章的脚注信息由WordPress的wp-posturl插件自动生成

所谓远程调试，顾名思义，就是在本地调试运行在远端设备上的程序。远程调试在嵌入式系统的开发上应用的比较多。嵌入式设备上内存、磁盘空间都比较有限，可能无法容纳整个gdb的调试环境和符号表；即便可以容纳，也需要对gdb进行交叉编译，比较麻烦，所以更常用远程调试的办法。像网友yorker这样在本地调试远端服务器上的程序，也是一种应用。

远程调试最简单的办法是使用gdbserver。gdbserver是一个非常小的程序，大小不到100K，因此可以方便的拷贝到嵌入式设备上，交叉编译也很简单。使用gdbserver，就可以使你的程序与远端的GDB调试器通讯，接收并执行调试命令。

gdbserver在大多数Linux系统中已经包含，不需要特别安装。如果你需要交叉编译，到GNU GDB网站上下载gdb的源代码，在里面你可以找到gdbserver。

本文将主要介绍如何在vim使用pyclewn进行远程调试(关于pyclewn的介绍，参见Easwy的的另外一篇文章：vim使用进阶: 在vim中进行GDB调试 – 使用pyclewn)。实际上，本文中所涉及的命令都是常用的远程调试命令，你可以直接使用gdb或ddd来执行这些命令，进行远程调试。

我们还使用在pyclewn一文中的程序做为调试示例，对那个程序做了一点修改，原来该程序需要由标准输入读取一个数字，现在则改为由命令行参数中传入。修改后的程序在这里下载。

现在我们准备开始调试。我们把编译好的二进制程序拷贝到一个名为Easwy_remote的计算机，然后在Easwy_remote上执行：

gdbserver Easwy_local:333 ./factorial 4 

上面的命令执行完后，屏幕输出如下(你的输出可能稍有不同)：

Process ./factorial created; pid = 7532
Listening on port 333 

上面的gdbserver命令的含义是：使用gdbserver启动./factorial程序，并传入参数4，而gdbserver监听在333端口上，等待远程GDB程序中的连接。命令中的Easwy_local表明允许来自主机Easwy_local的连接，不过目前的gdbserver版本实际上是不检测所连接的主机的。

现在，我们在Easwy_local主机上启动pyclewn，并在所打开的gvim窗口中执行下面的命令：

:e main.c
:Cmapkeys
:Cfile factorial
:Cbreak 15
:Ctarget remote Easwy_remote:333
:Ccontinue

上面的命令，首先打开main.c文件，然后执行pyclewn提供的mapkeys命令，加载pyclewn的按键映射。然后使用file命令加载所要调试的程序，并在main.c的第15行设置一个断点。

需要注意的是target remote命令。这条命令告诉GDB连接到主机Easwy_remote的333端口，进行调试。执行完这条命令，我们就连接到了远端运行的程序。接下来就可以像调试本地程序那样进行调试了，在上面Easwy使用的continue命令，使程序执行到断点处，然后继续调试。

下面是远程调试的屏幕抓图：

点击查看大图

gdbserver不仅可以像本文中这样启动一个调试进程，它还可以连接到一个已经运行的进程上对其进行调试，例如，用gdbserver Easwy_local:333 –attach 1235命令就可以使gdbserver连接到进程ID为1235的进程。

更多关于vi的内容，请参见Easwy的博客上的其它文章。

文章的脚注信息由WordPress的wp-posturl插件自动生成