Thinking, Dreaming, Flying

在Windows上用过EmEditor的人应该知道用EmEditor打开的所有文件都会以Tab的形式共享单一的GUI，这样做的好处是，不过因为写程序的时候打开了太多的文本而把任务栏挤得满满的。在Linux下使用gvim却没有这么方便，每次打开一个文件都会新建一个新的实例，是在是很不方便。

网上常见的解决方法是使用-remote-tab选项打开，不过用过vim的人应该都会感到gvim内置的tab显示实在是很不好用，倒是一个bufexplorer的脚本非常受欢迎，该脚本以文本方式提供了tab功能，用起来非常方便。这个脚本有若干个衍生版本，我使用的是minibufexpl.vim这个版本。现在我们希望双击一个文件后能够在bufexplorer中添加一个新的tab,简单的说就是使用drop命令打开一个新的文件。

查阅vim的api(h function-list)我找到了一个解决方法,  vim提供了远程执行命令的api:

remote_send({server}, {string} [, {idvar}])
发送 {string} 到 {server}。发送的字符串是输入键的序列。函数立
即返回。Vim 的服务器端不对键进行映射 |:map|。
如果给出 {idvar}，将 {serverid} 保存在以它命令的变量里，此后的
remote_read() 需要使用此值。
另见 |clientserver| |RemoteReply|。
该函数在沙盘里不可用 |sandbox|。

{仅当编译时加入 |+clientserver| 特性才有效}

这样我可以在命令行下执行：

gvim –remote-send “:drop [filename]” –servername “GVIM”

即可在现有的gvim实例中打开新的文件。将这一功能封装一下就变成下面的脚本:

#!/bin/sh
FILE=$1
GVIM=/usr/bin/gvim

SERVER=”$(gvim –serverlist | head -n 1)”

if [ "$SERVER" != "" ]; then
$GVIM –remote-send “:drop $FILE<CR>” –servername $SERVER
$GVIM –remote-send “:call foreground()<CR>” –servername $SERVER

else
$GVIM -f $FILE
fi

exit 1

该脚本在存在gvim实例的时候远程打开文件，否则启动新的实例。接下来只需要修改/usr/share/applications/gvim.desktop文件，将其中的gvim命令改为使用上面的脚本来启动就好了。

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. (Knuth, Donald. Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.)

避免过早的优化是编程中的一个观点，但是本文却是关于做事的。对程序员来说追求细节上的性能优化往往是得不偿失的，一些代码即使性能差一些也不会对整体的性能产生影响，真正重要的是系统中调用最频繁的热点部分才值得优化。这个观点也适用于做事。

我们总会希望事情变得越来越简单，简单到一个命令就可以自动化一件工作。但是这个自动化是需要成本的，在简化一件事情之前我们首先要明确这件事情是否值得简化。如果同样的问题反复的出现，在你的工作中持续的带来不爽的感觉，那么这时花一些时间去解决这个问题就是必要的。但是如果问题只是偶尔的出现，那么短暂的不方便即使忍耐一下也没什么。

这个感悟是在配置gvim的时候想到的，一开始我花了很多时间去安装各种各样的插件，学习了他们的用法，解决一些问题。不过我甚至都还没有大量使用vim的经验，所以那些插件是否真的对我的工作都有帮助。用掉的时间是否都物有所值还是未知数。就像firefox的插件一样，一开始处于好奇，尝试了很多插件，最后使用的只是其中的一小部分。

这个道理可以扩展到很多地方。比如项目的管理，那些方面是需要迅速解决的，那些是可以忍耐的。追求简单的生活但又不过分，不让这种追求成为一种不划算的负担，才是明智的做法。