gui2term.py是我用Python写的一个脚本，用于给仅支持 GVIM 的配色方案添加256色终端支持。介绍文章以及截图可以看Dante的《强烈推荐-将gui配色转化为终端配色的vim插件-gui2term-py》以及muzuiget的《Vim终端配色转换工具》。
GVIM 比起终端版的 Vim 来，支持丰富的色彩，而且使用 RGB 表示，更易于编辑，所以有很多配色方案都是只适用于 GVIM 的。但很多人不甘心忍受终端下丑陋的 Vim，于是，如muzuiget的博文所述，有好几个插件都尝试让终端版 Vim 能够使用为 GVIM 写的插件。但是，它们无一例外都是在 Vim 运行时动态转换配色的，估计有点影响启动速度。更重要的是，它们都是在 RGB 空间寻找最接近的终端色彩。这样造成的结果是，经常找到的颜色不是视觉上最接近的。甚至，在转换 spring 配色的时候，原本浅绿色的背景变成了灰色！
于是，我决定写一个脚本，永久性地为配色添加终端支持；同时，使用更好的算法来寻找最接近的颜色。所以，gui2term.py 是独立于 Vim 的 Python 脚本。所以，在最初的版本中我使用了 HSL 空间。没办法，不懂相关的色彩知识，只好凭感觉选择算法了。
前天，我收到了一封来自 Eric Pruitt 的邮件。他建议我使用 colormath 这个库来寻找最接近的颜色。我看了下，发现 colormath 依赖于 numpy。我可不喜欢这么大的依赖。于是，我从 colormath 以及别的地方找出了需要用到的三个算法：RGB 空间到 XYZ 空间的转换、XYZ 空间到 CIELab 空间的转换，以及一个名为 delta_e_cie2000 的 delta 算法。
新的算法比原先的要好一些。我测试了三个配色（lilypink、spring、以及另外一个自己修改的）。其中，有两个的转换结果与 GUI 版更为接近（但是其中一个我更喜欢之前的算法转的），另外一个与原来的算法结果相同。
除此之外，我也更改了寻找 rgb.txt 的逻辑，因为不少人用的时候程序报告找不到 rgb.txt 文件。现在，gui2term.py 会首先尝试使用 locate 程序寻找 rgb.txt。
