Juntong Liu

+1 using win10

Just try use SSH! that works for me

这个现象开始设计的时候就是这样的，实际上为此我还专门多写了很多代码。 这么做有两个原因： - 对于一些比较传统的输入法，原本就是允许整体缩写韵母而不允许缩写部分韵母，目前有些输入法允许这么拼写主要还是出于智能纠错的原因，整体上我希望和输入法行为保持一致 - 允许这样的缩写会产生大量重码，如果我要查找的是“古”，允许部分韵母就会导致搜索结果中混杂了大量的“光”，“棍”，“硅”等结果，这就会导致搜索“古”变得异常困难 不过这也有一个特例，如果是搜索串的最后一个拼音段，那么是允许韵母缩写进行匹配的，实际上我为此也加了不少特殊处理。 这也有两个原因： - 最后一个拼音段的拼写有可能用户还没有打全，是一个中间状态 - 允许这样的行为可以带来一个非常重要的特性：当用户的搜索串越打越长时，搜索到的结果永远是之前更短的搜索串获得的搜索结果的子集。这也就意味着，当用户在打入搜索串时，更新的结果可以通过只搜索上一次结果里存在的所有条目来获得，而不需要搜索全集，这在一些场景可以带来数量级上的性能提升。尽管现在PinIn的性能已经比较高了，大部分场景下已经不需要这个特性了，但是在早期版本的Jech里面这是非常重要的特性，否则可以说是卡到不能用。 当然，这部分的行为仍然是值得讨论的，如果有更好的解决方案也可以修改。

对于单个字符匹配的场景，PinIn还设置了一种特例，也就是所谓的音序匹配。如果用户对于一个汉字只打了拼音的首字母，那么这时即使声母是两个字母的，也可以完成匹配，也是就是“stou”可以匹配“石头”。主要也是俩原因： - 这么用的人似乎很多，而且有些输入法确实允许这种缩写 - 允许这种拼写方式也会造成重码，但是这种重码是可控的。如果我要搜索的真的是“四头”，那么只要把韵母打全，使得音序匹配的方式失效，就可以避免重码了 - 还有一个次要的原因，之前还有一个拼音搜索的mod，那个mod非常依赖这种拼写方式，所以把用户习惯都带过来了，不支持老是被人吐槽 对于这种方式，按理说“a”也应该能匹配“an”，“ang”才对，不过由于流程不同，所以这部分没有改进去。虽然说允许这种拼写也会有重码的问题，但是由于没有声母的字符本来就很少，所以重码还是可控的，这个特例是可以允许的。后边有空我应该会加进去。 至于其他的拼写，特别是上面说的“gu”“ga”等拼法的重码问题，还可以观望一下。如果每次“古”的时候，都会混杂“光”，“棍”，“硅”的结果在里面，那就会很影响“古”的查找效率了。本来拼音的过滤效果也没有特别理想，在我看来修改之后收益有限，但是损失是比较大的。

Yes, the lag is caused by calculation of the selected item. Once you change the item, the lag is gone. I know the performance problem for a long time, and...

这个崩溃应该是只有特殊的物品才会触发吧，应该是这个物品注册的有问题 后来我好像加了保护，我看看有没有合入1.12吧

@vfyjxf 版本号发一下呢？加速模式按理说应该是足够可靠的，索引树倒是可能会有一点风险。下次有搜不出来的也可以发出来看看。

@vfyjxf 这个是因为 AE 用的是正则匹配，置了忽略大小写的 flag，JECh 原来的实现没有那么细，没有处理这个 flag，导致大小写不能混用。AE 这个场景更怪一些，他在置位忽略大小写之后还将搜索串转了小写，现象就是只能搜小写英文，搜不了大写英文。不管这个特殊处理是出于什么原因，正确处理相关 flag 之后功能就正常了。

顺便说，当前版本 JECh 有一个诊断日志的功能 `/jech verbose true` 会把所有执行搜索的原字符串，搜索串和匹配结果都打在 mc 日志里。PinIn 的实时搜索几乎是无状态的，所以目前来看拿到输入参数之后大部分问题都可以稳定复现。

@GreatCoffee JECh 1.15.2-4.1.2 已兼容 Searchable Chests