missdeer之程序的野望

　　昨天跟小师妹约好的一起回去，今天早上8点半到了她楼下等她，结果居然电话都关机了，幸亏知道她同屋的室友的电话！原来小师妹还睡着，囧，睡过头了。幸亏我买早点的时候也买了她的份，等她下楼下已经9点半了。
　　不知道是不是因为放假的第一天，在上海的第一个收费站那里就慢慢吞吞地堵了大半个小时，真是烦躁。我们是要去杭州市三医院的，不过很郁闷的是，在高速杭州北路口拐出去后，就找不到方向了，导航也太蠢了，老是指向不知道什么地方。问了收费站的工作人员市区怎么走，好不容易到了市区，但又不知道怎么往市三医院方向走。在高架上走了一阵子，太堵了，小师妹很生气，后果很严重。我毅然决定下了高架，问了一个的哥，结果的哥居然说走高架本来是可以到的，不过好在他又帮忙指了另一条路。后来又问了个的哥，终于找到了市三医院，没想像的那么大，还找不到停车的地方，更郁闷的是停车的时候又刮到了，唉！
　　从医院出来大概是一个小时后了，即使有导航，还是有点提心吊胆的，不过这次似乎没怎么乱指，上了高速就好说了，但又有了另外一个问题，油不够了！小师妹说，怎么跟我出来尽是遇到意外情况啊。终于熬到绍兴界的服务区，加了油，之后总算是熟门熟路了。送了小师妹回家，我再自己回家，到家的时候已经快7点了。一天开了8个多小时，还真是累啊！

　　看到小师妹在日志中说寻找同类好难、心头一阵酸楚，使得我也感觉很难受，还有心疼。
　　回头看一下自己有比较清晰记忆的过去的十几二十年，确实也一直在不知不觉地寻找同类，只不过小些时候追求很少，有一起玩的小伙伴就觉得很满足。稍微大点了，有了一些自己想要的东西时，烦恼就渐渐增加。
　　那是非常孤独的日子，却又是非常希望能找到依赖的日子，但是一却找寻不到。我也不知道是从什么时候起，开始对寻找同类不抱有信心，甚至于绝望。直到昨天看到小师妹的日志，我才发现，其实我不再试图寻找同类，是因为我已经自以为找到了。找到了，并不是说就能见到，或能接触交流。那是一种认可，成为我的同类的资格的认同。只要知道ta的存在，不管ta在世界的哪个角落，偶尔能知道ta又做了什么事，那已经足够了。其他的事，就只剩下自己努力了，那些一直以来自身需要的精神鼓舞和激励，都可以从ta的事迹中获取。所以，在这个事件中，我可以高声宣布，我不孤独！
　　希望小师妹不再不安，同类无处不在。

　　Source Insight有大半年没更新了，我觉得以前一个同事说的没错，Source Insight可算是最不思进取的软件了，最后的几次小版本更新，都不知道到底有什么变动，反正我们最关心的一些问题都在。包括缺少Tab，缺少代码折叠，中文支持极差。不过总的说来，Source Insight的完成度是很高了，除了这三个缺点外，其他确实很难找出明显的问题来了。
　　我想做一个类似的源代码浏览工具，有几点Source Insight做得不错的地方，很值得学习。比如快速打开文件，快速查找函数和符号，上下文敏感的代码浏览，以及调用关系图示。Source Insight内建支持C/C++、C#和JAVA代码分析，其他的语言是通过扩展定义的规则实现的，这种方式也值得学习。

　　ZenCoding由2部分组成，ZenCSS和ZenHTML。其中ZenCSS只要简单的查表替换就可以实现，而ZenHTML相对要复杂得多。为了比较完整地给CodingStudio添加ZenCoding支持，花费了我一周时间，当然这一周我也是堕落了，工作时间和效率都很不乐观。
　　本来我已经发现用LPeg实现ZenCoding将是非常合适的解决方案，但看了一两天LPeg的文档后，还是有点迷糊，再看看ZenHTML的规则很少，硬编码实现也不是太复杂。
　　首先扫描是否当前表中已经有对应的项，如果没有，则下一步。
　　匹配E+E，将表达式按+分隔成多个子表达式，然后针对每个子表达式进行处理。
　　对子表达式匹配E>E，将子表达式按>分隔成多个包含关系的表达式，对各个表达式分别进行处理。
　　对表达式匹配E#name和E.name，到这步之后，E就可以查表了，而name部分仍然需要继续处理。
　　对name匹配E*N$和E*N，到这步后，就可以获取到所有信息了，然后向前回溯，组合成最终的字符串。
　　我这里的实现跟官方ZenCoding还是有点区别，官方ZenHTML是先匹配E>E，再匹配E+E的，我想我还是得照官方的改一下的。

　　俗话说，磨刀不误砍柴功。对于这句话，我一直都自认为是辩证地看待的，在某些工作前，先做些准备工作可以极大地提高之后的效率，好比Kunth老爹的TeX。不过很多时候，磨刀也是件很费时费力的事情，好比Kunth老爹的TeX。
　　这几天一直在考虑实现ZenHTML，这是一种极大提高hard coding效率的code snippet方法。其中有一种可以认为是一种“小语言”，呃，这是《UNIX程序设计艺术》中的说法，用GoF的《设计模式》中的说法应该算是interpreter模式。不管怎么说，反正就是有一项任务是要解释字符串，根据字符串的不同表达式来作出不同的响应。
　　刚开始的时候我是觉得这个解析工作似乎非常简单，没有必要把它提高到“语言”这种层面对待，只要识别出两三个操作符就可以了。不过后来马上发现，实现起来并不轻松。我意识到，用Lua实现的话，用LPeg将是最合适的解决方案。今天又翻出LPeg的manual来看，还是看得有点糊里糊涂。明天继续。
　　所以说，磨刀也费时啊！