missdeer之程序的野望

　　看到推友@davidx_me说有个叫WBIM的for Mac的五笔输入法，马上去下载了来试用一番。之前一直用系统自带的那个五笔型输入法，相当不好用，不但字符小，应该是GB2312的吧，而且连候选提示都没有，其他的常用选项更不用说了。试用了WBIM后，就爱不释手了，虽然跟小鸭、极点神马的在可配置选项上有所差距，但总体来说，已经可以说是鸟枪换炮了。
　　它有着大部分常用的输入需求的选项，比如繁简切换、中英文标点、全角半角、空格，还可以自定义翻页的快捷键，可以自定义用户词库，比较遗憾的是貌似不能自定义选择候选的第二三项的快捷键，不过好在五笔输入绝大多数是选择第一项的，所以也可以忍受。
　　再有一个还算满意的是上屏速度不慢，虽然偶尔还是有点呆滞，不过也在可以忍受的范围内。
　　最后要说一下，这个软件目前貌似是免费的，这对于混迹于人傻钱又多的Mac用户群中偶尔几个穷人来说，实在是个福音。

　　Lua跟众多其他开源的脚本语言一样，都没有一个官方的或绝对统治地位的IDE。而与诸如Python和Ruby这些大红大紫的脚本语言相比，Lua算不上一个流行的语言，也就是当年WoW的推出，带动了Lua的发展，相应的，Lua的开发工具也就显得更加落后，不但缺少一个比较正统或权威的库集合，还缺少好用的编辑器。之前我已经介绍过LuaPack，一个与Lua For Windows定位类似的开源项目，提供了几十个常用功能的第三方库打包。这回就介绍一个目前看来最好用的Lua IDE，叫DForD LuaCoding，它在LuaPack中也集成了，但它是个共享软件，在LuaPack中集成的那个版本只有在每次启动时弹出个要求输入注册码的对话框，只要点击“试用”按钮就可以继续使用了，除此之外没有任何其他的时间或功能上的限制。但是在DForD LuaCoding的官方网站上下载的版本，除了弹nag窗口，还有试用30天的时间限制，之后就只能花99美元购买了，当然网上也有0day。
　　DForD LuaCoding采用解决方案、工程组织方式来管理文件，任一时刻最多可以打开一个解决方案，而每个解决方案中可以有任意多个工程，这种组织方式与Visual Studio类似。另外，DForD LuaCoding还有通过文件名快速定位并打开文件的功能，这在Visual Studio没有直接的支持，需要装像Visual Assist X之类的第三方插件才行。这个功能对于一个解决方案中包含了大量文件的情况下特别有用。
　　DForD LuaCoding使用Tab浏览多个打开的文档，得益于Scintilla控件，语法着色，代码折叠等现代代码编辑器常有的功能几乎都有。不过由于DForD LuaCoding的定位是一个专业的IDE，而不是一个通用的代码编辑器，所以跟SciTE、Notepad++这种编辑器相比，就少了一些平常不太用的功能，比如复制行，交换行等等。不过总的说来，作为一个IDE内嵌的编辑器，当前已有的功能足以满足99%的编辑需求。
　　DForD LuaCoding提供了一个有点模仿TextMate的Code Snippet功能，不过TextMate中叫Tab triggers，该功能全部通过Tab键完成，而DForD LuaCoding中使用了三个不同的快捷键分别用于缩写展开和编辑热点前后跳转。这两种方式可以说各有优缺点吧，总的说来，我个人不太喜欢TextMate中一个Tab具有不同含义的作法，而且DForD LuaCoding中的三个快捷键分布得还算方便。
　　DForD LuaCoding提供了一定程序的Auto Completion，即自动完成。对Lua标准库的支持比较完善，不过也是因为Lua标准库很小很简单吧，呵呵，还支持几个其他的第三方库。但要说的是，该Auto Completion功能的准确性不高，有时把当前文档中的单词都列出来了，有时把所有库的表名列出来了，有时把所有函数名列出来了。不过实话说，有了这个Auto Completion，只要记住前几个字母，后面可能的候选字都列出来了，仍然可以减轻记忆负担，减少击键次数和拼写错误。另外，DForD LuaCoding对标准库中的函数，还提供了简单的call tips说明，只要鼠标光标停留在函数名上几秒钟，就会弹出一个tooltip，显示出该函数的简单说明，了胜于无吧。
　　最后值得一说的是DForD LuaCoding提供了Lua脚本调试功能，包括断点、单步等，操作快捷键与Visual Studio中的一样。只不过对第三方嵌入Lua解释器的程序进行调试的支持就不怎么样了，这方面要向Decoda学习，尽管Decoda做得也不好，不但速度暴降而且稳定性也略差，在这点上可以算是一大竞争点，但Decoda的其它方面在DForD LuaCoding面前就一无是处了。
　　总而言之，DForD LuaCoding可算是目前能找到的最好的Lua IDE了，但在Auto Completion和调试方面还有很大的提升空间。

　　昨天鬼使神差地想下几部爱情动作片看看，结果果然不幸中招了，乱78糟地起了一堆的进程，然后装上QQ医生，删那些可疑文件，最后不幸地不能进入系统了，一登录进桌面就立即自动注销了。于是只好恢复到出厂状态了，郁闷的是那块硬盘上的其他东西都备份不下来了。说起来，有各种备份措施可以使用的，但我仍然杯具了，是有原因了。
　　首先，我的笔记本自带的光驱不能工作了，这是一大杯具。进入Access IBM的备份和还原界面后，虽然有备份选项，还能找到硬盘上的所有数据，但即使在USB口上接了下刻录机，也找不到那个可写媒介。IBM的软件果然糟糕哇！
　　其次是我使用硬盘的方式有问题。一直都是整块硬盘的使用，不分区，然后有一块外接硬盘通过USB口使用。实践证明，外接USB硬盘已经有好几次貌似都因为USB的问题把整个分区甚至全部分区都弄得不能访问了。
　　最后要说的是，网络备份只是小孩子过家家的玩意儿，当然，我只是使用那些免费的服务，不但空间容量小，而且传输速度慢，以及到目前为止并没有证明其可靠性有良好的保证。
　　所以最后的结论是，等手头开始宽裕了，就装个高配置的台式机，最好能配个RAID，这样应该算是比较可靠的了。

　　我一直在寻找，甚至试图自己编写一个Source Insight的替代品，主要看中它作为一个源代码阅读工具，并具有良好的通用代码编辑功能。如果一定要找出同类产品来，还真是比较难，也许Komodo IDE和SlickEdit在通用代码编辑器的范围上可以往上靠，但在代码阅读器的范围内，实在很少见，可能doxygen和understand for C++可以勉强算是一类，但实现方式差别很大。现在有了DForD SourceCoding，总的说来，它是最接近Source Insight定位的同类产品。
　　DForD SourceCoding具有良好的中文支持，这得益于Scintilla控件的完美实现和ICU的强大兼容性。Source Insight的中文支持一直是其软肋，多年来没有什么实质性的改进，无论是保存项目文件的路径字符，还是文件中的字符，凡是中文，都很有可能出现轻重不一的问题，DForD SourceCoding则完全没有这些问题。
　　DForD SourceCoding使用Tab栏多文档界面，很难想像如今还有一个拥有大量用户的多文档界面的软件，居然没有Tab栏，Source Insight就是那么一个独树一帜的软件，以至于有牛人通过逆向工程等手段，给Source Insight开发了外挂，通过外挂给Source Insight添加Tab浏览等功能，可谓用心良苦。
　　还有一个大问题是DForD SourceCoding的代码编辑器是支持代码折叠的，而Source Insight至今仍无任何迹象显示要在这方面有所改进。代码折叠也算是众多Source Insight用户特别期待的一个功能了，对于现在一个完整的代码编辑器，基本上可算是标准配置，可是比较遗憾的是，这个功能似乎连外挂也是不能指望上了。
　　当然DForD SourceCoding也有不少缺点，比较明显的是，速度比较慢，比起Source Insight不是差了一两个数量级。其次，DForD SourceCoding的代码分析功能相比Source Insight来说，不够精准。DForD SourceCoding直接使用了ctags和cscope来进行代码分析，而Source Insight应该是对cscope进行了一定的改进，而且跟编辑器结合得更紧密。另外，DForD SourceCoding虽然本身是基于一个Lua脚本语言扩展的架构实现，但它并不开放这个扩展构架以便用户进行二次开发，而Source Insight则是向用户开放了脚本扩展的能力。所以说，DForD SourceCoding还需要持续改进，才能彻底战胜Source Insight啊。
　　最后有一点值得说的是，Source Insight比较贵，DForD SourceCoding的定价才是它的一半多一点，当然这要看用户如何选择了，是否少花近100美元买80%功能的呢？

　　在Lua神作《PIL》中操作XML的示例是用expat库的，众所周知expat是用类似SAX的接口的，这里介绍一下使用其他的库来实现DOM接口操作XML。
　　可以使用的库有几个选择，包括ltxml，xerces，rapidxml等等。ltxml使用TinyXML和TinyXPath提供的服务，xerces使用Xerces-C++提供的服务，而rapidxml则是使用RapidXML。这三个库我都有过一段时间的使用，不过都没怎么深入过。总的说来三个库各有特色，呃，其实是它们依赖的C/C++库的特点，ltxml我不是很喜欢，当初用的时候发现不知道为什么，同样一段代码执行多次后，打开并读取XML文档就会出错。于是后来转用xerces，它倒是基本让人满意，不过得附带一个Xerces-C++的DLL，感觉有点不爽，而且Xerces-C++应该说是比较完整的实现了XML的几个接口标准，但xerces只是封装了其中DOM读写的很小一部分接口。而rapidxml胜在运行速度飞快，从RapidXML的项目主页上可以看到一个简单的横向评测结果。xerces和rapidxml的Lua接口非常相似，除了几个节点类型常量的名称和载入的表的名称不同外，其他的读写接口名称和签名几乎一模一样，它们的源代码可以在它们的项目主页上通过svn下载得到，但需要用户自己编译，当然也可以下载安装LuaPack，LuaPack提供已经编译好的xerces和rapidxml文件，但要注意的是由于使用VC2010进行编译，只能在Windows XP SP3或更高版本的Windows系统上运行。
　　下面以rapidxml为例，简单演示一下如何操作XML文档。
　　新建一个XML文档，并保存：

　　require “rapidxml”
　　local doc = rapidxml.parse( “” ) — assign root node xml text
　　local root = doc:root()
　　for i = 1, 10 do
　　　　local new_child = root:append( string.format( “test_node_%d”, i ) ) — create new child node
　　　　new_child:set_attr( “index”, tostring( i * 10 ) ) — append new attribute named index with value i *10
　　　　new_child:set_text( tostring( i [...]