默认值改为nil是不是更好？non-nil 给debug用
1 个赞
名字用fanyi-quiet是不是更好？verbose给别的用
我感觉 quite 跟 verbose 差不多，基本没啥其他信息可以输出了
最近加了一个 fanyi-sound-player-support-https 新选项，如果你确定你的播放器是支持
xxx https://example.org/voice/a.mp3
这种调用方式，那么就把它设置成 t 吧。原来是要求程序把 - 当做 stdin，但是这是 posix 的一个约定，Windows 下的程序可能都没考虑过兼容 posix。
你们在 Mac 上使用fanyi.el 时，反应快吗？我这很慢，有时要等2分钟，有时等20-30s 就出结果。不知道有什么方法可以诊断？
同样的配置，在Windows 系统上就很快，几乎是实时的。
fanyi.el 做的事情非常简单，就是 url-retrieve 然后渲染。渲染又是非常快的，因此判定下来只可能是网络原因。如果确定查某个单词非常慢的话，用如下命令诊断
time curl 'https://dict.cn/xxxx'
如上是海词词典的 url，如果是其他 backend 有问题的话，可以看其他文件里 fanyi-etymon-provider 的定义里的 :url 是啥，然后将 %s 替换成对应的单词。
真的有点奇怪。用你的方法在eshell 里面测试，速度都挺快。 然后我设置逐个backend 使用，还是很慢。
至于网络，我测试过上网都没问题，用代理和不用代理都是通的。
(url-retrieve url (lambda (_status)
(message "done")))
那直接用这种方式来调用呢？我猜测可能是 UA 的导致的
执行下面这段代码的结果是 done：
(url-retrieve "https://dict.cn/happy" (lambda (_status)
(message "done")))
结果瞬间显示的，是不是表示这个词典是通了？
对的，可以 wireshark 抓包一下嘛？好排除是网络的问题。wireshark 最后保存 pcap 文件然后发到论坛上就好了
不好意思，今天在外出了。刚刚用wireshark 抓了包，不知道怎么发送到论坛😓，于是发送到了你的 Gmail 邮箱，麻烦帮忙看看。
ps: 还发现一个现象：
通过 fanyi-dwmi 命令启动，手动输入想要查询的单词，有些单词会瞬间查询到结果。但是第二次尝试有可能又是很慢。
谢谢大佬,挺好用的,已经把linux版本有道丢一边了
收到 pcap 的那封邮件了，这分析起来好累啊，让我再仔细理理……
辛苦了！我昨天又测试了一下，有时正在等待查询结果时，移动一下鼠标到fanyi的buffer上，会在3s 左右得到结果。但这个行为不能稳定重现。
1 个赞
这个状态功能不错，晚上回去试试 Mac 到底是什么问题。
不用 use-package 时怎么设置 fanyi-providers？我用的是 straight.el，没用 use-package。
还想建议一个功能，从历史词中选择，或者是在显示页面可以前进后退查看历史。
(custom-set-variables
'(fanyi-providers '(fanyi-haici-provider
fanyi-youdao-thesaurus-provider)))
README 里也更新了。
这个建议不错。个人觉得从历史词中选择更直观一点，而历史前进、后退的话有点猜的意思。
已经新增一个 fanyi-from-history 命令了，可以直接M-x调用。如果是在 fanyi buffer 里的话，按 h 也行。
遇见单词 给的解释也太简单了吧，感觉还不如海词的释义 
如果还要集成帐号的话还是有点用的，但是如果仅查询单词释义且速度上还不如海词和有道的话不是很想集成。