原本也打算用 widget，但是它似乎有问题。同一个 buffer 擦除之后再利用，就会出现错乱。
应该是我使用方式不对，同样没搞清楚 widget 用法的还有有内置的 eudc.el，它也有同样的问题，重现步骤：
-
M-x eudic-query-form。
- 在 minibuffer 随便输入点什么。
- 在弹出的窗口中点
[Reset]。
- 重复步骤 1，然后整个 buffer 变成了一个大号的
editable-field。
现在想是不是可以用 overlay 标记一块区域（例如 my-editable-field），然后拦截 self-insert-command 来，当光标处在 my-editable-filed 内，就暂时把 read-only 去掉。
再不行就把内容提取到 minibuffer 来编辑。
目前观察到的有两个问题：
- 添加了
widget 之后必须调用 widget-setup 才能生效。如果后续追加了 widget，再调用 widget-setup，就会使得之前的 widget 丢失部分属性。
- 有 widget 的 buffer 擦出不干净，最终会剩下一个空白
editable-field，接着就导致上面所述的问题。
看来widget还是不太行，widget作者写完之后跑路了，现在也没人维护。我之前想研究下，发现完全没用EIEIO，而是用symbol propery，结构挺碎片的，也就没改进的兴趣了。
不知道你用没用过deft？deft的输入栏就只允许两个操作：输入和删除，光标默认在最后面不能移动。跟isearch的minibuffer一样。或许可以整个overlay，上面用keymap限制只能在末尾输入和删除。这样还有个好处：输入栏可以做成固定长度，超出长度的话可以把最前面的截掉不显示，变短了再显示回来。不知道我描述地清楚不清楚。
当然更简单的是像你说的用minibufer，在输入框上回车就弹出minibuffer编辑，讲道理效果也不差。
大概也可以用marker做占位符？不知道和uuid比起来有什么缺点
可以把那个占位符颜色设置为背景颜色，不就不那么突兀了么？
这种最好还是自己写一个函数，因为和主要功能关系不大
我就是从那个链接下载的，已经用上了。这个字典是破解的吗？
1 个赞
1913年写的，没有版权啥的了吧。应该是public domain。
最终决定采用 minibuffer 方案，增加快捷键以修改/交换语言参数，我感觉使用起来比在 widget 上跳来跳去更流畅：
新增函数:
multi-translatemulti-translate-amend-query
3 个赞
支持保留多次查询结果（默认关闭），并提供了相应的函数和 Imenu 以便在各段落之间跳转和折叠段落。
@stardiviner 另，google-translate 的异步改造有在继续码？如果比较麻烦的话，我想我可以考虑写一个基于 web 返回结果的简单实现。毕竟这个包主要还是用来对比长句翻译的(单词有一个词典能翻译就够了)，而且的确 web 翻译的结果更好。
上次看过觉得麻烦之后就一直没有动手取实现，主要是我太懒的缘故 
。还是你写一个web返回结果好了。
刚刚再确认了一下前面提到的这句的翻译。发现 API 返回的结果跟 WEB 终于一致了：
(google-translate--request "zh-CN" "en" "修复部分翻译结果未能显示的问题")
;; =>
;; "[[[\"Fix the problem that some translation results could not be displayed\",\"修复部分翻译结果未能显示的问题\",null,null,3,null,null,[[]
;; ]
;; ,[[[\"51171d70a5b6c2485a24361038890141\",\"zh_en_2020q2.md\"]
;; ]
;; ]
;; ]
;; ,[null,null,null,\"Xiūfù bùfèn fānyì jiéguǒ wèi néng xiǎnshì de wèntí\"]
;; ]
;; ,null,\"zh-CN\",null,null,[[\"修复部分翻译结果未能显示的问题\",null,[[\"Fix the problem that some translation results could not be displayed\",0,true,false]
;; ,[\"Repair some problems failed to show the translation results\",0,true,false]
;; ]
;; ,[[0,15]
;; ]
;; ,\"修复部分翻译结果未能显示的问题\",0,0]
;; ]
;; ,1.0,[]
;; ,[[\"zh-CN\"]
;; ,null,[1.0]
;; ,[\"zh-CN\"]
;; ]
;; ]
;; "
从返回数据看，更合理的翻译放在了第一位，原先不太顺畅的翻译放在了后面。
难道 API 比 WEB 滞后一段时间？
最近想把 sdcv 加到后端中，发现一个问题：
manateelazycat 的 sdcv 将 melpa 中的 sdcv-search-with-dictionary-args 改为了 sdcv-search-with-dictionary
mepla 都不是我上传和维护的，我的插件都不在 mepla ， 请不要给我报 melpa 上引起的 issue, 谢谢！
我知道 melpa 上面的 sdcv 不是你维护的，没有报相关的 issue ，只是在 multi-translate 这边提醒一下，如果使用你的版本而不是 melpa 的版本会报错。
1 个赞
DeepL 的翻译后端可以参考 deno-bridge - #45，来自 manateelazycat 不需要弄 API Key 就可以一直用。
1 个赞
