应该就是在dump的时候刚好崩溃了？
另外关于google_translate的更新：我ran out of input之后至今没恢复，可能是ban掉了。但我chromium网页里google translate正常使用。我新使用的github:ssut/py-googletrans方案，没有google_translate稳定，偶尔某些词会挂掉，导致对应的那个词ov渲染失败。这两天大量开网页渲染，暂时没问题，不过我继续观察两天吧
@ginqi7 更新一下：早上八点多的时候又错乱了一次？翻看了dropbox的历史版本记录，568kb变成了399kb。 这次emacs好像没有崩溃。
我好奇地点开了dictionary.json，发现json文件末尾的括号也没了，以致于重启emacs再打开dictionary-overlay时会报错，unable to send to a closed websocket。
再更新：我用dropbox历史版本恢复了那个568kb的文件，恢复的瞬间dictionary.json变成了个582kb的文件，也就是说14kb的数据差值是正常保存在内存里？
我好奇地点开了dictionary.json，发现json文件末尾的括号也没了
感觉像是 dump 操作到一半的时候，python 程序挂了，或者是这个json有什么问题。
再更新：我用dropbox历史版本恢复了那个568kb的文件，恢复的瞬间dictionary.json变成了个582kb的文件，也就是说14kb的数据差值是正常保存在内存里？
不太可能正常值还在吧，emacs 都重启了。神奇的现象。
这种写入数据有问题的情况，还不好解决呢。 
1 个赞
新增了一个提交，支持orjson 解析 dictionary.json 本地词典，如果用户安装的orjson 则使用orjson 如果没有装，则使用 built-in json 包。
据说 orjson 比默认的python json 包快不少。但在 dictionary-overlay 当前的场景可能作用有限。 用户的 dictionary.json 词典通常不会太大，并且在 dictionary-overlay 应用启动时就已经加载完成了。后续也是定时保存到文件，json 解析的性能影响不大。
后续可能会考虑，用户数据每次查询、修改时直接从文件读取、写入，而不是选择定时保存。
2 个赞
不知道有没有办法支持短语，英文里除了专有名词外很多单词都是多意的，根据后面接的短语意义完全不一样。如：
“tease”: “揶揄者”
而如果是 “tease out” 则能够确定是 “梳理” 的意思
@tangxinfa 目前dictionary-overlay的底层逻辑是使用python的tokenizer来剥离buffer中的每个词，然后再用snowballstemmer进行词干词根(不具有实际词意)提取。暂时还无法支持短语吧?
另外由于d-o设计本身就不想对原buffer进行过多侵入性干扰，以致插入过多词意破坏排版，所以只取词典第一释意。如果想要精确查词，其实可以给dictionary-overlay-lookup-with参数绑个查词命令上去，比如popweb-dict-youdao-pointer / youdao-dictionary-lookup-at-point (可能有误) 这类能获取当前光标下词汇的命令。
不过我在想是不是可以把多种释义扔进help-echo里，或者popweb-dict / posframe 里，鼠标或者光标一经过就自动显示全部释义。
感觉挺实用的。我阅读慢就是因为分词比较费劲，没有阅读汉语的那么熟练。
果然好东西啊
看起来像是，不同buffer 的结果互相干扰了。你用的是最新版本的 dictionarly-overlays 吗？
@ginqi7 我最近也观察到互相干扰的情况了：Kill buffer 后切换到下一个buffer, 感觉原进程还在工作，会带到新buffer里。而switch-to-buffer/pop-to-buffer 可能不会受到影响 (我没有仔细观察)。
@ginqi7 另外，d-o 是不是也可以多进程 render? 根据网络好坏和buffer长短，有时候render时间长了，有点儿不耐烦，但又不能干别的，只想再开一个进程render以便稍后阅读。
我个人的使用场景: elfeed 这种已经提前排好顺序的，可以直接预渲染下一个。
抄了一下，为了跑起来注释掉了一些不懂的
直观感受，一键标注和自动跳转很方便，但就是每次要等差不多一秒，感觉卡，不知你使用中如何，是因为重新 render？
是的，我加了很多个人设置，只是为了展示一下dictionary-overlay 可以怎么和其他pkg配合。所以直接抄是没法用的。
关于“一键标注”，不知你指的是哪个功能？
关于自动跳转，取决于生词量多少。生词少基本无感，生词多就会有“粘”住的了感觉，一般都低于0.1s？“粘”的感觉是因为每次 mark-word 后都要从头到尾更新生词表。似乎可以继续优化机制，不过我现在对python不熟悉，继续围观大佬的项目。 
关于跳转后居中，因为我这儿会出现光标和hl-line分离（不确定是不是孤例），我暂时关闭了。
l 是跳转到下一个生词，可以按 o 来标注成认知词，很实用 
双键的 kb 试成功了，不过 popweb 弹出的窗口应按什么键消掉才能让point还在原处呢；还有如何设置一个键只让它发音不弹出窗口呢
也许我的电脑旧，所以实感不止0.1s
生词两个词表我已经导入了不少单词，抄了你的配置后感觉似乎有些之前已经确认过的词也冒出来似的，比如 Dad hello the he guess 什么的，一方面有可能我记错了，另一方面配置里这句
dictionary-overlay-user-data-directory (concat path-emacs-private-dir "dictionary-overlay-data/
上来就报错我就直接注释掉了不知是不是这个造成的；我还注释掉了一条字体颜色的，不过正文字体有时整段会变绿，倒也不影响
btw: 乱说些我的猜想，这个生词表是在内存里的一个 dict （定时写回磁盘）? 按说生词数量应该在几千个左右吧，内存理论上不应该吃紧？ 要是直接追加到另两个 buffer 里呢会改善吗
btw2: 像won’t 里的 won 会被拆成一个单字（词），还有 men 会被译成 “闷”
btw3: 似乎应该增加一个忽略的功能，有些人名啥的感觉放入 known 或 unknown 都不妥，建议加一个 ignore.txt
btw4: macos 上启动 emacs 时会失焦，观察似乎是因为有个 python在前台， 不知是 dictionary-overlay 还是 eaf 的问题，另外我退出时会有成对儿的进程在不知正确不正确
哈哈我说的也不准，大白话就是下雨天那种浑身粘粘的感觉。可能0.2？再多就肯定是因为生词量太大了。
强烈推荐透析模式，连续标几天后差不多都是高级难词和专业术语、以及人名地名这种无法穷尽的高亮了，可懂可不懂。我最近都是认人名模式了。
关于已经确认过的词，一种可能性是stemmer的解析法导致的，我手机码字，脑子糊了，解释的不一定对。另一种可能是本地json和内存中的json文件合并时发生错误了。针对后一种不知道你有没有dropbox，扔进去，随时恢复生词本和熟词本，因为它有版本控制。不过话说回来，后一种错误的话，可能会导致一直出现send to closed websocket的错误。所以我并拿不准原因。有时我也有这种闪回的印象，明明已经标注了啊。好在用久了，生词少了，次数越来越少了。
突然出现全部词汇加颜色，那肯定是json文件出问题了。
关于这个，你还是使用默认设置吧，那是我自定义储存位置。
目前的机制确实是这样的，然后最近加入了本地修改与内存合并机制，似乎还不是100%可靠，不可靠的原因之一包括emacs Crash时内存的内容还没dump出来，于是出现了文件破坏、存过的词又没存进去，下次又出现了的情况。作者上面提到改进读取写入机制的计划。
这个就是stemmer的固有问题了，没有办法。won和won’t从stemmer这个库的角度来说都是一个妈生的。
我认为做不到，因为穷举不尽。不过常用人名字典应该是有可能的。
我的经验看，应该是eaf/popweb系列的，macos毕竟在emacs届毕竟只是四等公民。
最后：我就是个普通的 d-o 用户，以上回答只是基于个人出发的一些观察，不能算是包作者的观点，应该有些错误。
只发音不弹出窗口的命令 popweb-dict-say-word
1 个赞
添加 overlays 是根据 buffer 名字判断的。
从代码里看，如果 buffer 被kill，它不会添加overlay 到其他buffer里。
但是，kill buffer 之后又开了一个同名的buffer应该会导致这个问题。例如 describe-function 生成的buffer 都叫"Help"，切换不同的查询，buffer 名字都是一样的。上一次未处理完的结果会到加载到下一次生成的同名buffer里。
@donaldlo 你这边遇到的是类似的情况吗？查看的一直是一个同名的buffer？
要根据 buffer 对象来做key，名字不靠谱。
我的主要渲染对象是elfeed，名字确实从头到尾都是elfeed-entry，应该是这个原因了。