小廖同学在google reader上共享了一篇《Remote Pair Programming with Screen and Vim》，突然想起来这正是我们上个月在体验结对编程时使用的一个技巧。
Screen是个非常强大的终端工具。强大之处之一就在于有个 -x 参数，能够连接到已经存在的screen会话之中。那天老大从2009敏捷中国年会上回来，让咱们试试结对编程。我们没有Google或者Fog Creek那么好的条件，那就挖掘一下现有工具的潜力吧。
两个人用同一个用户ssh到一台工作机上。一个人用screen启动一个会话，另一个人用screen的 -x 参数连接到那个会话上去。这样，每个人的动作都会即时的反映到另外一个人的屏幕上去，没有主从关系，任何操作，也并不限于Vim。这里我们只是可以用Vim做结对编程，实际上用这个做一下shell的教学啥的也很不错。
这样做的好处是可以远程结对，没有空间限制。当然，结对编程的一个好处就是两个人在一起可以随时沟通，这个就是另外的讨论了。
2009年10月7日星期三
2009年8月4日星期二
代码边线
今天闲逛的时候看到Intel官方blog上的一篇帖子《给VS2005的编辑器添加右边界线》，很有意思，因为好的代码风格是代码成功的一半。
Vim能不能也有相同或者类似的功能呢？google之，Vim果然不负我望（http://stackoverflow.com/questions/235439/vim-80-column-layout-concerns）：
highlight OverLength ctermbg=red ctermfg=white guibg=#592929
match OverLength /\%121v.*/
这段代码设置了一个新的配色方案叫OverLength，背景红色前景白色，第二句话将其和每行超出120个字符的部分进行匹配。什么意思呢？换句话说，在执行了以上代码之后，Vim会用红色高亮你编辑的文本每行中超出120个字符的部分，像这样：
虽然不像Visual Studio里面用线标出界限那么显而易见，但和textwidth等选项一起用起来也足够了：）
Vim能不能也有相同或者类似的功能呢？google之，Vim果然不负我望（http://stackoverflow.com/questions/235439/vim-80-column-layout-concerns）：
highlight OverLength ctermbg=red ctermfg=white guibg=#592929
match OverLength /\%121v.*/
这段代码设置了一个新的配色方案叫OverLength，背景红色前景白色，第二句话将其和每行超出120个字符的部分进行匹配。什么意思呢？换句话说，在执行了以上代码之后，Vim会用红色高亮你编辑的文本每行中超出120个字符的部分，像这样：
虽然不像Visual Studio里面用线标出界限那么显而易见，但和textwidth等选项一起用起来也足够了：）
2009年5月10日星期日
Vim与中文分词
Vim的"w"、"e"等一系列快捷键无法支持中文已经在vim_use和vim_dev中讨论过多次了，但是貌似没有开发者愿意给Vim写一个关于此问 题的补丁。我前一段时间研究了一下，发现让Vim在这方面支持中文确实是不现实的。在这里写一下原因，如果有人想继续研究这个问题，至少可以参考一下。
解决这个问题最直观的想法就是让Vim调用外部的中文分词库分词，然后把光标移动到正确的地方。相应的困难有两点：Vim不愿意和外部进程通信；Vim集成中文分词器很困难。
Vim的众多开发原则中，有一点是非常重要的，那就是可移植性。Vim运行在很多平台上，不止是*nix、Mac和Windows，还有VMS甚至 QNX。任何一个Vim的特性补丁能否被检入，不止取决与这个特性的紧急程度，还在很大程度上取决与这个特性的可移植性。Vim不愿和外部进程通信也正是 基于这个考虑，因为不同操作系统的通信机制千奇百怪，要设计和维持一套统一的协议是很困难的。没有和外部进程通信的渠道，让Vim调用外部分词库也就无从 谈起了。
使Vim用外部的分词器是最好的解决方案，因为在统一接口的条件下，这样可以保持很高的灵活性，在多个分词器之间切换。既然这样不行，那分词器可以集成进 Vim么？可惜，答案是很困难（不是不可能）。Vim关心的另一个非常重要的原则就是性能。Vim运行的环境可以是有图形界面的，也可以命令行。特别是在 命令行下，延迟是不可忍受的。幸运的是现在的中文分词库的性能都还不错，一般都有上百kb/s的处理速度，每秒都在十万字以上。另外，既然是集成进 Vim，那在众多中文分词库中应该选用哪一个呢？还有一个不利的因素就是现在中文分词都都需要词库，而这个词库是很大的。这么大的一个词库如果集成进 Vim，那下载起来会很困难。再者词库是需要更新的（程序会自己学习新词么？嗯，也许会吧，十年之后……），这就是大麻烦了，还要和网络通信，大大的不 行。
即便有个牛人把上面的麻烦都解决了，写出来了一个可用的补丁，和Bram他们讨论的差不多了，那也需要在一个branch中测试个一年半载来尽可能的找出所有bug（可以参见vim_dev的patches页面）。那时候，任何一个开发者应该都已经被磨的没脾气了。
看起来万事俱备，实际上满是窟窿 T-T
这个问题最好的参考，也是前车之鉴，就是Vim的拼写检查部分。在Vim中输入:h develop-spell可以查看帮助文件中关于拼写检查当年的讨论结果。最终拼写检查没有使用现成的Aspell，而是Vim自己实现了一份。Vim和Emacs的不同之处很明显，这是Vim的特色，但是在这种情况下这种自给自足的小农思想也成了Vim的一圈桎梏吧。
解决这个问题最直观的想法就是让Vim调用外部的中文分词库分词，然后把光标移动到正确的地方。相应的困难有两点：Vim不愿意和外部进程通信；Vim集成中文分词器很困难。
Vim的众多开发原则中，有一点是非常重要的，那就是可移植性。Vim运行在很多平台上，不止是*nix、Mac和Windows，还有VMS甚至 QNX。任何一个Vim的特性补丁能否被检入，不止取决与这个特性的紧急程度，还在很大程度上取决与这个特性的可移植性。Vim不愿和外部进程通信也正是 基于这个考虑，因为不同操作系统的通信机制千奇百怪，要设计和维持一套统一的协议是很困难的。没有和外部进程通信的渠道，让Vim调用外部分词库也就无从 谈起了。
使Vim用外部的分词器是最好的解决方案，因为在统一接口的条件下，这样可以保持很高的灵活性，在多个分词器之间切换。既然这样不行，那分词器可以集成进 Vim么？可惜，答案是很困难（不是不可能）。Vim关心的另一个非常重要的原则就是性能。Vim运行的环境可以是有图形界面的，也可以命令行。特别是在 命令行下，延迟是不可忍受的。幸运的是现在的中文分词库的性能都还不错，一般都有上百kb/s的处理速度，每秒都在十万字以上。另外，既然是集成进 Vim，那在众多中文分词库中应该选用哪一个呢？还有一个不利的因素就是现在中文分词都都需要词库，而这个词库是很大的。这么大的一个词库如果集成进 Vim，那下载起来会很困难。再者词库是需要更新的（程序会自己学习新词么？嗯，也许会吧，十年之后……），这就是大麻烦了，还要和网络通信，大大的不 行。
即便有个牛人把上面的麻烦都解决了，写出来了一个可用的补丁，和Bram他们讨论的差不多了，那也需要在一个branch中测试个一年半载来尽可能的找出所有bug（可以参见vim_dev的patches页面）。那时候，任何一个开发者应该都已经被磨的没脾气了。
看起来万事俱备，实际上满是窟窿 T-T
这个问题最好的参考，也是前车之鉴，就是Vim的拼写检查部分。在Vim中输入:h develop-spell可以查看帮助文件中关于拼写检查当年的讨论结果。最终拼写检查没有使用现成的Aspell，而是Vim自己实现了一份。Vim和Emacs的不同之处很明显，这是Vim的特色，但是在这种情况下这种自给自足的小农思想也成了Vim的一圈桎梏吧。
订阅：
博文 (Atom)