shot

@IndexOutOfBounds #5

> - skip_too_short_threshold: 0
> match_re: ^[\s\S]{0,300}$ # 丢掉 300 字以内的短文
> action: drop_feed

如果我理解正确的话，这是通过 yaml 来配置和启用“系统内置”的插件。
已经有了初步的插件化支持。

我更期望后继能扩展到支持用户自己编写插件、上传系统、沙盒执行。

比如说我订阅了 V2EX 的 RSS 源，希望有一个功能：在主题发布两天后统计它的回复数，感谢数和红心数。
这可能是一个非常小众的需求，不一定会内置在系统里。那就只能既往插件机制来支持用户自行编写。

大赞！

请问是否有计划做一个插件系统：通过执行自定义插件，对 RSS 内容进行标记/过滤/增强/……
如果要支持插件，也许我也能贡献绵薄之力。

我去年就整理了 RSS 阅读器的一些需求，主要关注插件支持能力。但是一直拖延着没动手……
https://github.com/users/HuangJian/projects/1/views/1

Rime 处理这个问题的标准答案是使用「模糊音」。

speller/algebra/+:
- derive/^([zcs])h/$1/ # z, c, s => zh, ch, sh
- derive/^([zcs])([^h])/$1h$2/ # zh, ch, sh => z, c, s
- derive/([aeio])n$/$1ng/ # ang, eng, ing, Ong=> an, en, in, on
- derive/([aeio])ng$/$1n/ # an, en, in, on => ang, eng, ing, ong
- derive/([iu])a(o|ng?)$/a$1$2/ # tain => tian

---------
启用模糊音会带来两个问题：
1. 候选词数目会大量增加。如“zhangk”会候选「展开」，不过我还没有体感到候选条目增加引起的性能卡顿；
2. 增加的候选词可能会带来预料之外的词频排序。还是“zhangk”，我机器上「展开」会排在「掌控」前面。

因为我用的是全拼，所以写了一个根据输入编码和候选词拼音匹配程度重新排序的插件，也算处理掉这个问题了。
https://github.com/HuangJian/rime-frost/blob/hj/js/sort_by_pinyin.js

@yibie #12

> 有没有基于这个开发的新插件，作为一些例子？

看看我们的实力！ 白霜拼音的所有 Lua 插件都已完美重写为 Javascript 版本 。

https://github.com/HuangJian/rime-frost/tree/hj/js

@Vitta #4

> 成熟的话应该很好用了，这样的话是不是就可以支持 api 请求了

如果是说通过网络调用来实现类似「云输入法」的功能，已经有人基于 Lua 插件引擎做过了。

理论上说，Javascript 插件引擎应该也能做，而且比较 Lua 还有一个优势：充斥宇宙的 npm 库 。
一个障碍是：quickjs 不一定能无缝使用 nodejs 的类库。这个问题暂时还不在我的计划内。

@Vitta #4

> 成熟的话应该很好用了，这样的话是不是就可以支持 api 请求了

如果是说通过网络调用来实现类似「云输入法」的功能，已经有人基于 Lua 插件引擎做过了。

@luoyou1014 #2

> 有个疑惑，Rime 类型的仓库，不会有老外看吧，为啥 ReadMe 默认是英文的

1. 在技术领域，英文表述通常比中文更严谨更精准。
2. 用英文能避免大陆简体和港澳台繁体的表达差异（ Rime 创始人和很多贡献者都不是内地人）。
3. 据说有基于 Rime 的日文和韩文输入法。
4. 稍微提高一丢丢技术门槛，也许后面能减少一些不太认真不够严肃的社区噪音。

感谢分享，期待后继内容。