似乎扩展是很流行的样子，各种浏览器，foobar2000，谷歌拼音，WPS，都可以用扩展。

其中，有的软件成功了，令人爱不释手，比如像 Firefox，foobar2000。有的软件却没有因为扩展成功，比如谷歌拼音。或者说扩展没有给人带来好感，比如 IE 浏览器。

我觉得作为一个支持扩展的软件，最重要的就是扩展要比较有用，可以做一些事情，这一点上谷歌拼音做得就不好，由于扩展而变得比较成功的软件在这方面做得都比较好。其次，扩展要容易开发，再往后，出于安全的考虑，扩展的能力要受到约束。这两点 IE 相比 Firefox 就弱了一些，不过 Firefox 的扩展写起来还是挺麻烦的，比如其中的多国语言化就非常麻烦，对于不同的地方要使用不同的方法，总共有三种。而由于 Firefox 的灵活性，出现了 Mozilla Jetpack 和 GreaseMonkey 等，都可以让扩展写起来方便一些。

在很长的一段时间内，我觉得编写软件，技术含量是最重要的， 一个更好的算法可以带来更快的速度，或者更好的结果，当然用户体验就会好。但是现在看法有些改变，因为目前，很多东西不是需要从头做起的，除非出于学习、版权目的，或者是原先的项目代码烂到不能看而没法维护，没有必要重新实现别人已经实现的东西。大部分软件应该在乎实用性，在不违反版权的情况下，尽量使用已有的东西。

从一开始，我觉得 ibus-sogoupycc 这样一个输入法的技术含量肯定不如 sunpinyin，Linux 下的输入法用 sunpinyin 就不错了，一度怀疑是否要有将 ibus-sogoupycc 写下去的必要。但是现在，我觉得是有必要的，因为在中国大部分有网络的地方，这样一个输入法用起来是更舒服的，至少对我自己来说。

使用信号很弱的无线网，输入起来感觉也不错

出于同样的实用性的考虑，我提供了输入法扩展能力。本来我想提供一个完全兼容谷歌拼音的接口，但是后来觉得谷歌拼音的扩展接口设计得并不好，和目前输入法的无需选词流畅输入有冲突，没有遵循的必要。

开头提到的这个表情在这里： ，不难找吧。

扩展的设置应该放在用户配置文件中，目前添加一个扩展的方法是：

ime.register_command(key, modifiers, caption, script)

这里，key 和 modifiers 都是数字类型，后两者是字符串类型。

修改用户配置文件后一般要重新启动输入法才能生效，可以右击任务栏上的 ibus 图标，选择重新启动。

Hello world
下面的代码注册了一个用 Alt + H 可以激活的扩展，只要输入法被激活，无论处于中英文状态，都可以用这个热键运行这个扩展。

ime.register_command(("h"):byte(), key.MOD1_MASK, "hello", "ime.notify('hello world')")

重新启动 ibus 之后，按下方形的扩展按钮(ibus-1.2.0.20090927 版本下，方形按钮会消失，这是 ibus 的已知问题，此时通过热键仍然可以运行扩展)，可以看到一个标题为 hello 的菜单项，单击它，就可以运行扩展。

输入法扩展菜单

插入系统时间

ime.register_command(key.Shift_R, 0, "插入系统时间", "ime.commit(os.date())")

这里的 ime.commit 也是输入法提供的方法，用来直接向客户端程序输入文字，os.date 是 Lua 标准库函数。这段代码注册了一个用 右Shift 激活的插入系统时间的功能。

Lua 的标准库函数在扩展中都是可以用的，比如可以用 os.execute('mousepad &') 在后台运行一个 mousepad。

执行 Lua 代码

ime.register_command(('L'):byte(), key.SHIFT_MASK + key.MOD1_MASK ,
  "执行 Lua 代码", "ime.execute('ime.notify('..ime.get_selection()..')')")

这段代码注册了一个用 Shift + Alt + L 热键，把选中内容当做 Lua 脚本执行，并用桌面提示显示结果的扩展，这里因为有了 Shift 辅助键，所以要取大写字母 L 的 ASCII 码。其中使用方法 ime.get_selection 获得选定文字的内容，ime.execute 用来把一个字符串当做 Lua 脚本运行，双点号是字符串连接操作。

这个扩展可以比较有用，比如当选定 315+23*6145 这样的表达式之后，运行一下扩展就可以知道计算结果，也可以选定 ime.VERSION 这样的内部变量，查看其内容。甚至可以选定一段 ime.register_command 代码，动态添加扩展

“回音”效果
不知道从什么地方开始流行这种效果，我想说明的是，声明一个函数并且在扩展中调用是可以的：

function echo_effect()
	local s = ime.get_selection()
	for i = 1, #s, 3 do ime.commit((i == 1 and '' or '，')..s:sub(i)) end
end
ime.register_command(('E'):byte(), key.SHIFT_MASK + key.CONTROL_MASK,
  "产生回音", "echo_effect()")

这里简单地使用了 3 个字节 作为步长，所以只能处理纯中文。对文字 “这是回音你懂吗” 使用这个扩展会得到：”这是回音你懂吗，是回音你懂吗，回音你懂吗，音你懂吗，你懂吗，懂吗，吗”

全半角切换
输入法本身没有提供全半角切换功能，但是通过扩展可以实现类似功能：

ime.second_punc_map = {}
function toggle_punc_map()
	ime.second_punc_map, ime.punc_map = ime.punc_map, ime.second_punc_map
	ime.apply_settings()
	ime.notify('已切换到' .. (ime.punc_map['.'] and '全' or '半') ..'角')
end
ime.register_command((','):byte(), key.CONTROL_MASK , "全半角切换", "toggle_punc_map()")

注册了 Ctrl + 逗号 作为切换热键，并会用桌面提示显示切换结果。

全双拼切换
可以仿造上例写出：

ime.register_command(0, 0, "全双拼切换",
  "ime.use_double_pinyin = not ime.use_double_pinyin ime.apply_settings()")

前面填写的两个 0 表示这个扩展没有热键，你也可以再加上一句 ime.notify，使得切换的时候有桌面提示。

对缓存的操作
缓存是存在全局的 request_cache 中的，可以直接对其操作：

function show_request_cache()
	for i,v in pairs(request_cache) do
		ime.commit('"'..i..'" => "'..v..'"\n')
	end
end
ime.register_command(0, 0 , "查看缓存", "show_request_cache()")
ime.register_command(0, 0 , "清空缓存", "request_cache = {}")

其中的 ime.commit 方法用来向客户端插入文本，还有一个方法是 ime.request，用来向输入法提交一个拼音请求，比如下面这段代码片段将向输入法提交《春晓》的拼音：

for _, v in pairs
{'chun mian bu jue xiao', 'chu chu wen ti niao',
 'ye lai feng yu sheng', 'hua luo zhi duo shao'} do
	ime.request(v)
	ime.commit('\n')
end

给自己发送飞信
输入法全局配置文件默认加载了 socket.http 和 socket.url 模块，可以用它们来访问网络。

比如，下面的代码通过 api.bz 这个在线接口把选定文字内容通过飞信发送给自己：

function send_sms(content)
	http.TIMEOUT = 2
	local res = http.request('https://sms.api.bz/fetion.php?username=15566119320&password=nevermind&sendto=15566119320&message='..url.escape(content))
	ime.notify(res or '飞信发送失败', content, 'info')
end
 
ime.register_command(('m'):byte(), key.CONTROL_MASK + key.MOD1_MASK, "飞信发送", "send_sms(ime.get_selection())")

以上填写的飞信用户名和密码皆为虚构，实际用的时候需要改一下。

简繁体转换和翻译
使用 Google API 来翻译文字，从简体中文翻译成繁体中文就实现了转换成繁体

function google_translate(text, langpair)
	local url = 'http://ajax.googleapis.com/ajax/services/language/translate?v=1.0&q='..url.escape(text)..'&langpair='..url.escape(langpair)
	http.TIMEOUT = 1
	local res = http.request(url)
	if res then res = res:match('"translatedText":"(.-)"}') end
	return tostring(res or text)
end
 
ime.register_command(('t'):byte(), key.CONTROL_MASK + key.MOD1_MASK ,
  "转换成繁体", "ime.commit(google_translate(ime.get_selection(), 'zh-CN|zh-TW'))")
ime.register_command(('e'):byte(), key.CONTROL_MASK + key.MOD1_MASK ,
  "翻译成英文", "ime.commit(google_translate(ime.get_selection(), 'zh-CN|en'))")

写在最后

这是一个悲剧。

Lua 作者根本不相信多线程，原因是现在的主流语言中连 a = a + 1 都不是原子的，谈什么多线程呢？

我曾经做过一些尝试，确实让程序多线程地执行 Lua 代码，又共享一些全局数据，不是轻松的事情。我也想到一些解决办法，但是都太麻烦了，于是就偷懒不管那么多了。

这有什么影响呢？影响就是目前输入法执行 Lua 代码是单线程的，扩展中的 Lua 代码会造成阻塞。在有网络请求等操作的时候，要注意控制超时，否则程序可能被认为没有响应了，各种死法都有可能出现

目前输入法的自由程度到了可以随意 AOE，比如用 os.execute('pkill Xorg')，就可以干掉许多无辜者。正所谓权力越大，责任越大。到底安全与否，就看扩展中的代码自我约束得如何了

由于天之痕而喜欢上轩辕剑系列的我，在云之遥上市之后，看着台湾玩家慢慢地通关，和他们聊起了输入法，被告知无虾米输入法目 前是超过新仓颉，最流行，最好学，最快的输入法，连幼儿园小朋友都在学。

难以想象把注音、字形、英文单词混合编码的输入法是什么样子，但无虾米输入法就是这样的输入法，它还是拥有 Windows 98 时代的灰色界面，并收费的繁体世界最流行的输入法。我尝试练习一段时间之后，聚精会神地输入最基本的字根的速度只有双拼的四分之一，又由于繁体字和简体字 有很大区别，注音和拼音也有区别，决定放弃无虾米。

拼音类的输入法的通病，重码很多，一不留神就会输入错字。我想去尝试一些其他的形码输入法。简体的形码输入，比较流行的就是五笔和郑码，虽然似乎五 笔的名气大一些，但是郑码看起来更加好，我决定在寒假期间学会它。

世事万变，突然有一天，我收到一用户的邮件，其中提到了对 ibus-sogoupycc 的建议，还指出了几处错误。本来觉得用 Linux 的人就很少了，用双拼的人就更少了，同时使用 Linux、双拼，还要是 ibus 的用户也许就只有十几个。但是那封邮件让我觉得世界上这样的用户多了起来，这个几个月没有变化的项目是时候去动一下了。我重新考虑了形码输入法是不是值得 去学，认为不用选词、两个键一个字、不用按空格确认的双拼肯定比形码快不少。至于云服务器识别错误的汉字，我想到了微软拼音的“纠正”功能，一种不会打扰正常输入而提供纠正错字的办法。于是我决定在寒假期间实现这些想法，并放弃学习形码输入法。

不用选词的双拼

说到微软拼音，我一直觉得它是输入法界最有技术含量、最规范的。它规范到了不愿意接受网络词汇（2010版本之前），就让其它的拼音输入法有了可乘 之机。微软拼音的整句输入感觉很舒服，输入完拼音之后，不用多余的空格确认，可以按一个标点，表示确认输入并加上这个标点。写 ibus-sogoupycc 的时候我参照了微软拼音的一些行为，比如：选中文字后，可以将文字转换回会拼音，再开始选词，用于纠正错字；使用双拼的时候，屏幕显示的是全拼的提示。

主流拼音输入法需要用数字键选词，而数字键按起来不方便，这就有了用空格， Ctrl，Alt 等键来选词的特殊需求。那么如果用 asdfjkl 来选词，不就会更好吗？ ibus-sogoupycc 默认就是这样，为了区分需选词按键和拼音按键，输入完拼音后需要按下 Tab 键，才开始选词，用 h 和 g 键翻页。

没想到，真正开始写程序之后，很快就进入了令人寝食难安的调试周。程序似乎在各个地方都能出错，在我的代码外。使用了各种正道歪道，无济于事。多线 程程序，你也许是有体会的。几天后实在找不到原因，就在 ibus-devel 讨论组提问，感谢 P.Huang ，我知道了像 glib 和 dubs 这样的东西并不愿意知道目前运行的程序是多线程的，你需要调用它们的函数通知一下才可以。相比之下 glibc 就很听话，使用 `-pthread` 编译参数就可以使得大量的 glibc 调用变成可重入的版本。

让我好几天辗转反复的问题居然就这样添加两个函数调用解决了，虽不甘心，但确实可以继续做下去了。寒假最后的两天，原来以为会比较难做的通过外部词 库选词，实际上比较容易就完成了。2月27日，我在项目的 Download 页放上了 0.1.0 的版本以及 Archlinux 用的安装包，更新了许多 wiki 页。但是随后我自己就发现了几个问题，不乏有低级错误。2月28日，我的一个好朋友过生日的这一天，我修正了我自己发现的那些问题，并通过测试，确保没有 问题。把版本更新到了 0.1.1 ，更新了 wiki 页。至此，我觉得是比较好了。

以前，用 Windows 的时候总是感觉到输入法比 Linux 好太多了，现在感觉倒过来了

官方给出的云输入法是基于web页面的，只能在浏览器中使用，目前只支持全拼，在浏览器中一旦转移到其它页面，就需要重新加载一次输入法，用起来成本很高。检查后发现官方的云输入法客户端其实就是向服务器发送了明文的全拼字符串，然后服务器会返回一段js脚本，包含了候选结果，往往第一个结果就是所需的，确实识别结果不错。Linux下的各种拼音输入法都没有Windows平台下的好用，既然搜狗云输入法是这样简单的AJAX请求，那么能不能包装一下它，让它在其他的地方也能用呢?

之前对ibus的示例代码有印象，觉得在ibus上面开发输入法比较简单，而且ibus这个平台看起来很可靠的样子，于是就开始动手了，这次从一开始就决定用C来写，写到中间的时候发现真的是自找麻烦 :-( ，许多数据结构如果用C++的话就容易多了，也免去了考虑内存泄漏等各种问题。

我用输入法的话，肯定是用双拼的了，于是就先去找双拼的代码，关于双拼，其实我以前已经写过几份了，在目前的本本上能找到的版本就是有一次修改sun-pinyin让它支持双拼的时候，那时的代码是为了达到目的而不择手段的，使用if else硬编码了所有的双拼组合，不仅看起来惨不忍睹，时间复杂度想来也不好。这次改用C语言的OO写法写了双拼的一个类，使用动态构造的简单的trie大幅提高查询速度。这里还用了char **[]这样的数据类型，写完后用pluskid上次在小课堂上介绍的valgrind检查内存发现没有泄漏，比较高兴 :-)

但是并不是所有地方都是这样顺利的，输入法的最麻烦的地方是对用户按键事件的处理，确实有很多很多情况，稍不注意就会出问题，确实在这个地方调试了不少时间，而且在这里改代码，改正一个问题的时候很容易产生新的问题 。为了让用户在服务器没有返回结果的时候还能继续输入，我使用了多线程去从服务器获取结果，为了数据完整，我在所有写操作的地方都简单地使用了锁，第一次写这样的多线程程序，死锁了几次，后来熟悉起来就没有再犯错误 :-) 当我写的差不多的时候，升级到了ibus 1.2版本，这个版本和我开发使用的1.1版本接口不一样，似乎改动的地方文档不全的样子，我只好又改成了1.2版本使用的代码，不过由此也产生了各种问题，可能到现在都还存在。

虽然自己发现目前的程序还会在某些时候不知道为什么而垮掉，而且似乎还有各种已知和未知的小问题 但我觉得基本功能已经不错，可以拿出去分享一下了，就放在了这里，也许能够交几个朋友或者是收到比较不错的建议呢

目前的情况在上面的项目主页有介绍，程序的主要特点就是多线程，用户输入无阻塞，以及支持双拼（到底有多少人用双拼啊，可怜的孤独的我… -.- ），没有选词功能，始终采用服务器返回的第一个结果，这样其实在鼓励用户不要去选词，少按空格确认输入的拼音，因为标点符号就附带有这样的效果(和微软拼音一样)，用户可以流畅而义无反顾地输入整句的拼音，不因为实际出现的汉字而打扰思考 :-) 如果网络流畅的话，实际体验是很不错的：

网络比较流畅的情况

在网络条件不好的地方，应该也是不错的吧，我模拟的网络延迟比较大的情况，大概会是这样的情况：

网络延迟明显(模拟)的情况

如果搜狗官方可以持续做这个项目并且不把接口改得没法看懂的话，这个项目还可以继续做下去，继续做的话有两个功能可以加上:第一个是输入一个字的话就不经由服务器了，这时候给出本地的符合要求的所有汉字列表，这样可以解决生僻字输入问题，也对个别汉字纠错提供方便。第二个是缓存一些比较短的词语，再次输入的时候可以使用缓存的数据(不过用云输入的话基本都是整句输入，不会缓存到许多数据的吧 )

这篇日志的前面500字就是用ibus-sogoupycc在无线网上写的，除了个别时候出现网络错误之外，确实是几乎没有错字(5个左右吧)，后面由于网络条件太差改用普通的拼音输入法了，明显感觉到正确识别率低了许多许多

总之,现在的情况还是多谢搜狗官方啊,希望这项服越做越好,可以一直用下去