在写这篇文章的时候，我正在尝试自己开发一个我自己认为能拿出去见人的IDE。当然此时此刻我只开展了一点点工作。所以这篇文章没有什么最终的指导性，而是在记录我开发IDE的思考过程。当然我觉得之前写了那么多东西除了开了源之后介绍了我的作品让大家可以更好的理解并学习以外，其实也没有什么大的效果（除了几篇置顶的教程我个人觉得还是有点效果的……）。因此我尝试做一下改变，把我的思考过程描述出来。一方面我自己可以从一个更高的高度来审视我自己，第二个就是如果你们想从我这里拿走什么，或者想教我什么，请自便哈。

    其实以前并不是没有开发过IDE，只是那个IDE除了语法高亮以外什么都没有，因此其实并没有什么大的用处。个人认为IDE要提供给你的功能有三点：智能提示、集成调试、辅助部署。当然在我眼中最厉害的IDE当属VisualStudio了，各种功能真是非常人性化，而且也跟我的观点比较一致：我只是想开发个编译器然后开发个makefile系统让别人可以方便一点用我的编译器而已，为什么我一定要用makefile来组织我的编译器源代码啊，一点都不方便（噗

    是个程序员都是这么想的哈。

    IDE还是好东西。前几天我在vlpp.codeplex.com上面checkin了一份我开发的语法高亮编辑器的雏形（下载后打开Candidate\CodeBoxControl\CodeBoxControl.sln），完全用C#写。我的Demo也是用的C#，外挂了一个可以分析C#的关键字、字符串和注释的代码着色器，在我的机器上（虽然我觉得比较强大，不过我的程序也是单核的，因此其实也只有2.7G的频率）着色一个将近10万行的程序只需要半秒钟。其实大家大可不必觉得C#很慢，其实是很快的，慢的是你的内心。

    当然我也做了一点优化，全文着色要半秒，不过其实你在编辑的时候是不需要总是全文着色的。所以我的着色器接口做了一点小限制：
    1、你必须用状态及实现，而且状态及的状态只能用int类型来表达。
    2、着色必须是上下文无关的。

    对于2可能比较难理解。首先C#那个可以检查出一个ID是不是一个类型然后变色其实根本不是着色器的任务（根据我的设计，你可以在另一个地方临时更改颜色，也能实现）。其次对于一个给定的任意字符串前缀，其着色效果不能跟前缀之后的任何字符有关系。

    因此我只需要记下每一行的末尾着色器当时的状态，就可以从任意位置开始到任意位置结束进行部分着色了。因此这里就有很多的优化空间。有了这些优化之后，我用我的Demo编辑一个将近10万行的C#文件的时候，那个运行在UI线程里面的着色算法丝毫没有让我觉得有延迟，只有在少数情况下（瞬间贴了好几万行代码，然后按ctrl+end跳到全文最后，我不得不对你贴进去的东西立刻着色）才会让你感觉到有小于半秒钟的延迟。所以我觉得这个设计已经可以达到我的要求了，因为我自己写的代码一般单个文件都没有超过1万行，所以偶尔给我一个小于0.05秒的延迟其实也是无所谓的……

    为什么可以进行优化呢。你可以想一下，如果我正在对某一行进行编辑，而且这一行后面的代码都已经被着色过了，那么如果你的改动都没有让行末尾的着色器状态发生变化，那么这一行后面的所有字符都不需要更改他的着色，因此我就可以只对你当前编辑的一行进行着色（唯一修改的其实也就只有那种多行注释，你一般也不会写很多这种多行注释的，都用的单行……）。一百来个字符的着色基本上可以忽略，因此无论你的文件有多大，其实着色速度是跟你平均每行的长度有关系，只有在极少数情况下才会跟你的行数有关系。这个时候你可以看到着色器两个限制的强大威力了吧。

    那么，当我们对一行代码进行断点的时候，代码颜色的修改是如何做的呢？为了这个东西去影响着色器那个强到可以忽略的效率实属杀鸡取卵，所以答案就是：外挂一个控制面板接口，让你可以在显示某一行的时候临时修改那一行每个字符颜色。听起来好像很影响效率，不过我们要相信，一行代码也就只有那么几十到一百来个字符，一屏幕的代码最多也就一两千个字符。任何语言无论多慢，对一个一两千那么长的数组赋值，也是奇快无比的，何况是C#这么快的语言……

    因此我们剩下的问题就是如何实现一个可以修改文字颜色的普通文本框了哈。经过我的3此研究，结论就是，不要用RichTextBox，你自己自绘从头写一个。第二个结论，凡是GUI最好都别用C++，无论GUI类库多么好，一个没有内存管理器就足以让你觉得很麻烦了，当然对于编译器本身我还是推荐C++的，因为编译器虽然算法复杂，不过结构简单，所有的内存分配都是可以预测的，因此delete起来非常有信心。

    最近一两个星期都在纠结如何实现一个简单的上下文有关的智能提示功能（至少按个"."会有个列表什么的）。这个明天再写了，今天只有一点点头绪，还没完全成型。