今天先放图哈。智能完成已经开始做试验了不过距离能看还差很远，所以今天先继续谈一下着色的事情。

    这就是我暂时实现的所有功能了。首先着色算法可以外挂，其次左边那个边栏（大小和绘制均可以订制）操作他的时候会发生什么事情也是外挂的。着色器与“断点变红”是分离在两个不同的插件接口里面的，原因上一篇文章说过了。你们可能还会注意到那个灰色的框框。那个框框的确是会被编辑器当成一个整体来对待，不过我绝对还没有实现折叠。因为在我的设计里面，如何进行折叠应该是插件的事情，控件本身只要处理好怎么编辑和显示就行了。还有一个比较难发现的就是，我这玩意儿也是支持输入法的，输入法的窗口会跟随光标移动……

    在开发这个东西的时候我尝试了两种新方法。第一种是MVC。MVC开发高亮还真是容易啊，不仅文字缓存部分（C#也是可以精确控制内存的哈）可以独立出来，连编辑操作（各种按键鼠标组合）其实也可以不做在控件里面。这样有什么好处呢，当然是可以进行高强度的单元测试了哈。第二种就是GUI自动化，光对类进行单元测试还是不够的，Visual Studio 2010为.net单元测试工程提供了一个Coded UI Test框架可以给我启动一个独立的外部程序（MFC写的也行，WinForm写的也行，WPF写的也行，网页都行）然后操作上面的各种控件最后拿到控件里面的信息。不过可惜的是我的文本框并没有按照Windows的UI Automation标准来实现（从而让盲人也能使用这个控件），因此只能进行键盘和鼠标的操作，至于我绘制的东西是什么则需要其他方法。C#跨进程怎么做最方便呢？当然是Windows Communication Foundation了哈。为了写足够的单元测试是要不惜一切D。不过显然WCF的服务不可能做在控件里，因此我的solution下面暂时就有控件工程、测试工程和被测试的“独立程序”工程了。

    有了GUI自动化测试，我在进行重构的时候，就可以放心的修改代码，然后执行测试程序，去外面喝杯茶。过个几分钟测试工程就会跟我报告一共挂掉了多少个case，只要修好就行了。这种方法杜绝了绝大多数由粗心引起的bug。如果你在公司使用类似技术来对付你的代码的话可以有效减少工作时间，从而让公司可以榨取更多价值。

    操作的组合还是比较麻烦的。为了全套支持，我特地操作了一下Visual Studio 2010的文本框，然后对一些我看不顺眼的行为经过修改之后，现在已经可以实现{LEFT, RIGHT, UP, DOWN, HOME, END, PAGEUP, PAGEDOWN, ENTER, BACKSPACE, DELETE}×{null, CONTROL, SHIFT, CONTROL+SHIFT}共44种操作方法。加上鼠标，突破半百。这么复杂的东西，如果没有足够的单元测试，也没有足够的GUI自动化测试的话，随便改个什么都很有可能发生问题的。所以开发这类程序的时候要十分小心，一定要写单元测试。

    至于着色应该怎么测试呢？只要有了WCF，就十分简单了。测试程序发送两个坐标，WCF服务返回坐标之间所有字符的颜色代号就行了。代号是可以在测试程序跟被测程序之间约定的，所以这种方法就让测试变得十分简单了。

    开发这一部分一共花掉我大约四天时间（假设不用上班每天能写8个小时，累计出来的）。当然平时要上班所以实际花费是要多一倍不止的。其实当我在纸上画出了上图C#着色器的状态机之后，也没想到实现出来速度这么猛的。虽然着色器使用状态机来实现已经是速度最快的方法了（经过大学4年写编译器的经验……不过我后来用C++做出了一个能根据正则表达式在内存中产生词法分析器的，比手写的更快），不过还是要感叹一下.net到了4.0还是比起当年的2.0要进步无穷多倍的哈。虚拟机可以在执行的时候才开始产生并优化x86代码，可以让程序越跑越快（非骗人，编译原理小白请自行学习），这还是静态编译其所不能达到的。之前还看过channel9上面的视频讲微软某个研究院在做一个全新的javascript引擎（看起来好像没有加进IE9beta），就是用了动态的两阶段profile+optimize+codegen的方法，通过为瓶颈代码使用激进优化方法，从而让总体的运行和编译时间的总和降到最低。生成X86什么的还是非常麻烦的，总之我已经被机器码囧了半年，暂时不想碰JIT了……当然这是迟早要再碰一次的。

    写到这里就先碎觉了，下一篇开始说之前在纠结的过程中产生的几个智能完成的方案。迟早都要把它给做出来的。