嗯，这种方式最用户来说最友好，我思考一下该以怎样的方式来提供
默认值改为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 也行。