---- 上一篇里说的想拿 Vim 当自编程序的 UI，基本已经做到了：

---- 底部的那个 buffer 属于 CSA 模块，这个新写的 Vim 插件就是负责充当外部程序在 Vim 里的界面，buffer 里显示的是外部程序的输出。关于用 Vim 来当 UI 的话题在 第一篇 里讲过。

---- 果然即使用 Python 接口建立了多个线程，也是没有办法让这些线程自动刷新 Vim buffer 里的显示的，况且还有上一篇里说的那个大 Bug。最后采用比较妥协的办法，负责监听的辅助线程还是建的，但是不产生任何输出，只修改后台数据。而主线程每次向外部程序发送输入之后，就 sleep 0.3 秒然后根据后台数据刷新显示，一般情况下都能即时显示外部程序的输出。另外再定义一个手动刷新的按键。

---- 要点记一下:

1. 上一篇里说的那个 bug，是 GUI 的问题，用终端版的 Vim 没事。GUI 版如果在后台建多个线程的话，只允许其中一个线程有可见的输出（也就是造成 Gvim 窗口内显示内容改变），其它线程只能修改后台数据。

2. 如上，即使多线程也不可能自动刷新 Vim buffer 的内容，但可以显示消息（不考虑 bug 的情况下）。自动刷新 Vim buffer 目前已知的只有一个办法：用 VimScript 的 feedkeys() 函数，但是有严重局限，相当于屏蔽了用户的其它输入。这个绝对不用。

3. 辅助线程监听外部程序的输出用的是 Python 的 select.select() 函数，可以监听一个 file descriptor 列表并返回其中有内容可读的 descriptor，但有一点要注意：在产生输出的外部程序已经终止以后，会出现 file descriptor 一直有效但读不到内容的情况，如果不注意这一点就有可能让监听过程陷入死循环，知道的话只要稍微处理一下就可以了。

---- 下一步打算升级程序的 Plotting 模块。现在这个模块还是测试性质的，上次试着画了 2000 多只股票自 2010 年以来的走势，全部单线程运行，花了两个多小时。现在打算改用 Python 的 multiprocessing 模块实现。据文档里说，这个模块与 threading 模块的接口十分类似，这就好了，以前那些关于 threading 的代码可以直接拿过来抄。以后批量执行绘图任务的时候，应该能省不少时间。

 

----------------------------------------------------- <以下补记> -------------------------------------------------------

---- 重大发现，感谢 依云 在回复里的提醒。以上要点第 2 条其实是不成立的。Vim 本身虽然是单线程的，但是通过 Python 完全能够实现多线程的特性。上面所说的辅助线程在监听到外部程序输出以后，就可以操作 vim.buffer 对象，这时 Vim buffer 实际上已经更新了，所缺的只是刷新显示的步骤而已。只要在刷新过程的最后添上一条 Vim 命令: "redraw!" 就可以了，出来的效果实在是 nice！

---- 这样一来，我完全想不到有什么是 Vim + Python 不能做的了。想起来在去年的时候，我想拿 Vim 当自编程序的界面，因为在 Vim 里找不到与外部进程交流的办法而被逼到去看 Emacs 。。。 如今看来，Vim + Python 真是个无敌组合，我忍不住要恶心一把。。。Emacs 你去 Shǐ 吧，哈哈，你的 Elisp 再强，能强得过 Python 吗？速度比不过 Vim，功能又比不过 Python。再想想 Elisp 里头那无数个括号，是要蛋疼到怎样啊？你那 N 个窗口，图片显示功能或许很酷，可是搁不住它慢啊！这事情一慢起来还有什么意思？好在 Emacs 早就顾及这一点，于是定义了更加蛋疼的操作方式，用 Emacs 的人，想快也快不起来，啊哈哈哈 ...

---- 以上讲笑，请浮云看待。如有用 Emacs 的看到，请先冷静 10 秒开骂 。。。

---- 既然这样，Conque 这个 Vim 插件就好拿出来再说一下了。确实像 依云 说的那样，它的实现可以有重大改进。Conque 是在 Vim 里模拟 Shell 终端的一个很流行的插件，它不同版本的实现曾经有过很大改变，但都使用了 Python 接口，插件负责底层交流的部分是 Python 写的。我在去年 7 月左右看过当时最新版的代码，学习了很多。首先，知道使用 Python 接口来编写 Vim 插件就是来自 Conque 的启发，这个还要感谢当时在 Vim-cn 群里跟我提起这个插件的网友 “Strange”。另外，Conque 使用了 Python 语言里负责底层系统操作的标准模块，比如 tty、select 这些，来与外部 Shell 进程交流，这些模块直接对应于底层的 Unix 系统调用，效率高而且可靠，我在自己写的程序里也用 select.select() 来监听外部进程，这也是从 Conque 里学来的。

---- 从当时的 Conque 的代码来看，它是单线程的，从键盘接收用户输入发送给 Shell 进程，而接收靠的是 Vim 函数 feedkeys()，以这个函数作为触发，不停地监听和提取 Shell 输出，经过格式、颜色处理以后发送到 Vim buffer 里。就像上面说的，用 feedkeys() 有严重局限，因为它完全模拟了用户的按键操作。这样一来，真正的用户就只能进行一个键的操作了。如果按键输入多于一个键，后面的键就会被 feedkeys() 冲掉。而 Conque 的解决办法，就是把键盘上几乎每一个键都做了映射，使得 Conque 能通过这些映射来区分是真正的用户输入，还是 feedkeys() 的输入，从而做不同处理。我觉得，这是个很无奈的做法。如果它对速度的影响还不那么糟糕的话，实际上它还屏蔽了 Vim 强大的编辑功能。如果只是把 Shell 原样不动地搬进 Vim 的窗口里是没多大意思的，能够在 Vim 里操作 Shell 的最大好处在于，在编辑那些火星文的 Shell 语句的时候，要能够毫无保留地使用 Vim 的强大编辑功能，这样才真正有意义。

---- 今天这个突破应该能够让以上成为现实，或许一半成为现实。。。因为还有 GUI 的那个大 Bug 在。是不是 Conque 的作者没有用多线程是因为，他当时就知道这个 bug 啊？为了顾及到插件的通用性，就只好放弃这个几近完美的解决方案了。因为这是 X 系统的 bug，我就叫你 X-bug 吧，万事具备，只欠踩死这只 bug！哈哈！

• 全局相关文章
• 相关文章

[取消回复评论]

昵称 登录 E-mail: *
Web:
Twitter:

当有新评论通过 E-mail 通知我

(输入验证码)

or Ctrl+Enter