在 Vim 页签中打开文件

这两天折腾让文件在 Vim 的新页签中打开（类似 Firefox 等浏览器）的特性， 发现让文件在页签中打开有非常多的优点：

1. 打开文件的速度更快（免去了启动 Vim 的时间）
2. 占用内存等资源更少（单个 Vim 窗口比多个窗口节省资源）
3. 任务栏更节省可用空间（不过 Windows 7 中还未支持任务栏多页签内容预览）。
4. 编辑过程中文件间可以快速跳转，缓冲区也可以共享。

我参考前辈的方案，做了更 自动化的处理 脚本， 将其中的 edit.with.vim.tabs.reg 合并到注册表就可以了。如果想还原为用窗口打开的方式， 再将 edit.with.vim.window.reg 合并到注册表中。

这个设置会让双击默认编辑器为 Vim 的文件，或者右键 -> Edit with Vim 都将文件在页签中 打开。开始用着确实挺爽，右键菜单中也没有了那些动态增加进来的已打开的文件的菜单项。 不过后来又发现不止如此，连“用 Vim 比较”(Diff with Vim)的项也没了。

重装了好几次，终于搞清楚了一些东西。注册表的

[HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers\gvim]
@="{51EEE242-AD87-11d3-9C1E-0090278BBD99}"

是关键项，他根据 gvimext.dll 来附加右键菜单的动态项，包括 Diff with Vim。 如果你不想有默认的新窗口中打开文件的“用 Vim 编辑 (&V)”(Edit with Vim)， 就需要把上面这项删除，不过这也会殃及 Diff with Vim。

我实在没有特别好的办法，我在注册表中做了一个 "Diff with Vim" 的项，但是这个菜单命令 会针对选中的多个文件各自执行一次；而不是执行一次，并将多个选中的文件作为参数 一次传入。这个肯定也能做到的，参看 Vim 默认的行为，和 WinMerge 等就知道，只求高手来帮忙了。

我目前不希望没有这个选中多个文件并 Diff 的功能（虽然它连快捷键都没有）， 所以只好保留了这个注册表项，为了避免快捷键冲突，只好修改了在页签中打开文件的 注册表项的快捷键。

或者用其他的文本比较工具，如 WinMerge，BeyondCompare。这样的话，直接删除上面的注册表项。

如果你有好主意，快来快来告诉我 : )

其他

另外给页签加上序号是非常有用的：

set guitablabel=%N.%t

尤其是在设置了这样的快捷键之后：

imap  :tabnext
nmap  :tabnext
imap  :tabprevious
nmap  :tabprevious
imap  :tabfirst
nmap  :tabfirst
imap  2gt
nmap  2gt
imap  3gt
nmap  3gt
imap  4gt
nmap  4gt
imap  5gt
nmap  5gt
imap  6gt
nmap  6gt
imap  7gt
nmap  7gt
imap  8gt
nmap  8gt
imap  9gt
nmap  9gt
imap  :tablast
nmap  :tablast

更多，但是不推荐(因为跟默认快捷键冲突)的快捷键设置：

" [CONFLICT] back tag history
imap  :tabnew
nmap  :tabnew
" [CONFLICT] window shortcut key.
imap  :tabclose
nmap  :tableclose
imap  :tabonly
nmap  :tabonly

更新 (2010/6/26)

今天想折腾一下 gvimext.dll ，因为这个是问题的本源，只要将它里面的“用 Vim 编辑”(Edit with Vim)加上参数， 改成新页签中打开的方式就好了，而且选中多个文件进行比较，好像也必须使用动态连接库的方式实现， 于是找到了这个 gvimext.dll 它让 Vim 7 支持新页签中打开。试用了一下，感觉有点啰嗦了，它让新窗口和新页签打开文件的方式共存，并且快捷键 仍然设置在新窗口打开的菜单项上。不过里面带有源码，我们可以改成自己喜欢的方式。

参考链接

• Vimfaq - Ubuntu 中文
• vi/vim 使用技巧: 在标签页中打开文件 (windows)
• 如何通过使用注册项 (.reg) 文件添加、修改或删除注册表子项和值
• Context menu issues with gVim in Windows 7 x64
• Show tab number in your tab line

Vim 自动补全成对的括号和引号

炫日分享了一个 自 动补全成对的括号 的脚本，【注】：原文代码中引号被转义成了中文引号，下面是修正后的脚本。

inoremap ( ()i
inoremap ) =ClosePair(')')
inoremap { {}i
inoremap } =ClosePair('}')
inoremap [ []i
inoremap ] =ClosePair(']')
inoremap < <>i
inoremap > =ClosePair('>')

function ClosePair(char)
   if getline('.')[col('.') - 1] == a:char
       return "\"
   else
       return a:char
   endif
endf

经此启发我增加了对括号和引号更智能的补全支持， 不过中文全角的括号和引号目前无法通过映射来实现， 对于跨行、转义的符号对的支持也不佳，如果有好的实现也请告知 : )

• OpenPair:
1. 如果当前行的括号已经成对匹配，则自动补全右括号 (I)
2. 如果左括号比右括号多，则自动补全 I(() (I() ((I) (()I
3. 如果左括号比右括号少，
   I()) 原样输出，不自动补全
   (I)) 同上
   ()I) 同上
   ())I 自动补全：左括号较少，且光标之后字符串进行一次递归上面的条件
• ClosePair:
1. 如果光标之后是一个右括号，向右移动一列 (I) ((I) (I)) ()I)
2. 否则原样输出。

代码见 gist: 449512

更新 (2010/6/24) 最后更新 (2010/7/9)

相关脚本

• delimitMate.vim (src)
• Making Parenthesis And Brackets Handling Easier

在 Google Maps 的街景视图里看实况足球

我承认我标题党了，这只是我的一个 idea 而已，并没有实际实现。

前几天有新闻称日本要申办 2022 年的世界杯，承诺将以 3D 转播赛况，还以全息技术将赛况投影到足球场上， 任何一个足球场都可以模拟现场实况，并准备研发全息电视，把赛况以全息技术在家庭里播放。 而实际上，日本在某些音乐会已经使用全息技术的实际应用（X-Japan的 Art of Life 的 15:36 至 19:13 之间都是以全息技术 制作的演出，直接观看19:10，然后等几秒钟就会明白）。

我的个神啊，这是一种怎样的未来。

在看南非世界杯的几个球场街景视图时，我突然想到如果模拟实况足球游戏，根据比赛实况，将比赛情形在类似的视图中 展现出来，会爽到什么程度啊。

伊 丽莎白港

内 尔斯普雷特

p.s. 现在的 Google Maps 街景视图，比 Google Earth 的 3D 模型要爽要逼真，不过街景视图无法以 3D 效果看鸟瞰图。

延伸阅读：

• 日本申办2022世界杯 许诺提供3D比赛直播
• 日本研发全息电视：用激光投射飘浮图像
• Google Trike
• 初音未来3D全息演唱会 | 宅映像
• 初音未来全息演唱会 - 初音ミク

用 Google Code 管理与发布 Wiki

由于 Dropbox 的墙掉，https 协议访问 dl 或 dl-web 子域 的方法也随之失效，虽然可以通过修改 hosts 来继续同步文件，但是 Public 目录再也 不能输出文化了。

我之前 在 Dropbox Public 目录搭建的博客和 Wiki 系统 也无法在线浏览了，为了能够继续 辅助文化局输出文化，我便利用万恶的资本主义国家 的 Google Code 来为我们服务了。

由于可以继续使用 Dropbox 来自动同步私有文件，所以可以保持 .wiki 文件在 Dropbox 中，其他自动同步的软件也可以用来做类似的事情。

将 Vimwiki 的 path_html 修改为 Google Code 的某个 svn 或 Hg 目录：

let g:vimwiki_list = [{...},
   \ {...},
   \ {...},
   \ {
       \ 'path'        : 'D:\My Dropbox\blog',
       \ 'path_html'   : 'D:\hotoo\blog',
       \ 'html_header' : 'D:\My Dropbox\blog\template\header.tpl',
       \ 'html_footer' : 'D:\My Dropbox\blog\template\footer.tpl'
   \ }
   \ ]

虽然 Vimwiki 目前的 toHTML 方法还不支持重新生成仅更新过的 wiki 文件，但是 svn 可以判断文件是否有真正被修改过。

另外 http://hotoo.googlecode.com/svn/wiki 目录存放的是 Google Code 的 Wiki 文件， 这里面的 wiki 文件无需通过 Vimwiki 导出 HTML，Google Code 会自动完成这一工作， 并可以通过 http://code.google.com/p/hotoo/w/list 浏览。而 Vimwiki 是 Google Code Wiki 语法的一个子集，所以基本可以天衣无缝的配合使用。

这也是不错的一个方案，除了需要 commit 之外，Google Code 比 Dropbox 的 Public 有过之而无不足，域名也是杠杠的。

另外不小心发现还有其他的托管方案，让防火墙筑的更高些吧，当局者把自己当猪圈养起来 比较好，做个专职的脑子又笨，目光又短浅的墙脚之猪也可以提高幸福指数的。

让 Vim 支持 LOG 文件

日志(.LOG)文件的基本上无章可循，各成风格。所以一般都是在纯文本模式下查看。 以普通文本的方式显示日志，基本没有清晰度和阅读舒适感。

不过一般来说，日志中是会有日期时间（格式非常多样），错误产生的地址，行号， 列号，日志类型（错误(ERROR)，信息(INFO)，调试(DEBUG)，警告(WARN)等）

据此，我为 .LOG 文件定义了一些语法着色的规则，将 log.vim 放至 $VIM\vimfiles\syntax(Windows) 目录，并在 $VIM\vim72\filetype.vim 中加入：

au BufNewFile,BufRead *.log         setf log

现在就可以在 Vim 中较清晰的查看 .LOG 日志了。

你也可以针对自己的实际情况，来自定义语法。

未知选项的表单设计

发现许多的注册表单设计中，性别部分的设计大都这样：使用单选按钮（radio）并默认选中一个（大都为男性，某些女性频道为主的可能为女性）。例如网页申请QQ帐号和注册网易通行证等

网页申请QQ （qq.com）帐号

注册网易（163.com）通行证

雅虎（yahoo.com）的设计比较特立独行，使用选择框（select），并默认不选中任何一个。

而雅虎中国（yahoo.cn）的设计也是使用单选框（radio），但是不选中任何一个。

按常理来说，注册系统并不知道用户的性别是什么，默认选中任何一个都不合理。yummy有一篇文章《中文按1，For English, press 2》提到“如果用户必须做出选择，那就先给他做好一个选择。”，这个道理在某些情况很不错，但是用在这里不合适。

如果不足够了解用户，就不要替用户做选择。

状态模式

现有的IM软件都有状态设置功能，常见的默认状态有：在线，忙碌，离开，隐身，离线，但是这些状态对应的选项是不可设置的，例如TM/QQ，选择在线或者忙碌，对应的通知铃声，接收消息方式都是指定、不可改变的，虽然这些默认设置在某些情景下可能很合理，但不总是这样。

TM/QQ 状态：可以使用默认状态作为模板附加消息来添加状态。

Gtalk 状态：可以直接在状态写状态信息，但是只有在线，离开和离线三种状态。

WangWang 状态：可以添加状态信息。
可以看出，基本上IM软件的状态信息只能向好友展示文本消息，告诉好友你当前的状态，有时候并不能真正帮助我们在某些需要的时候过滤某些信息，例如老板告诉秘书，帮我回绝所有约会和电话。
最近工作的时候发现，我希望工作的时候设置状态为在线，或者忙碌也可以，而且不想接收所有或某些群消息。例如上班工作的时候不想接受技术探讨群或娱 乐群的叽歪消息，但是要聆听部门或项目组的群消息，尤其要注意老板发来的消息，当然手工修改每个群的消息设置也可以做到，但是每次改都非常不方便，如果可 以保存为模式（如命名为“工作模式”，寂寞的时候想找人聊天可以设置一个“寂寞模式”），在模式之间切换就更实用了。
智能手机（如我的Smartphone）在这方面就做的不错，值得学习。Smartphone上有各种“情景模式”，如普通，静音，会议，室外，自 动，耳机，车载和免提，每一种模式的铃声类型，音量，包括模式名称等多项设置都可以根据用户自身情况改变（当然默认的情景模式设置也已经很合理了，但我也 有在一些特殊的时候，做一些适当的修改）。

下面使用Windows Mobile 2003的相关屏幕截屏

标签模式

目前的标签有以下几种模式(形式)：

1. 手动外联标签模式。
这种模式将标签和内容分离，用户需要为指定文档/内容贴上不同的标签。例如Gmail和新版Wordpress的标签。

优点：简单易用，可控性强。
缺点：需要为每个内容设置标签。


2. 手动内联标签模式。
这种模式将标签和内容融合，用户同样需要为文档/内容贴上不同的标签，并且这种模式因为没有明确的标签输入区（标签输入区和内容输入区在一起），容易导致忘记贴标签，对于及时性和不可修改性的应用不太理想。如Twitter就有这方面的第三方应用，参考hashtags。

优点：内容被语义化；标签本身简单易用，可控性也很强。
缺点：需要辅助标记，内容被干扰；容易忘记使用标签。

3. 自动内联标签模式。
这种模式需要用户手动设置标签集合，系统根据内容自动匹配标签。目前还没有发现这种模式的实际应用，比较接近的有关键字替换和对局部文本进行评论（忘记怎么称呼了，也没找到相关网址，请大家给提个醒）。关键字替换只是展示层的，用户可以根据内容发现（暂且称之为）标签，但无法通过标签找到匹配的内容（由此想到了搜索引擎）。

优点：标签自动化，用户无需操心内容和标签之间的关系。
缺点：要匹配到正确的标签并不容易，大概到真正的语义时代可以解决。

由此扩展另一种：

4. 内联标签兼容模式。
系统根据用户设置的标签集合管理标签与内容之间的关系，另外用户也可以手动管理标签。
优点：标签自动化；可控性强。
缺点：简单问题变复杂，包括系统实现复杂度和用户使用复杂度。

不过回头想想，标签本身很简单，有必要把它变复杂吗？自动化就是不想手动控制，如果需要手动控制还要自动化干嘛？