Closed gynamics closed 2 months ago
这应该是 url.el
的 BUG,我没仔细考证,不过使用 url.el
进行请求,即使是异步请求,有时候也会莫名其妙阻塞编辑器,挂代理的时候尤甚。以前也考虑过用 C-g
杀进程,虽然实现起来简单,但这种搞法似乎不太友好。
所以,最佳的方案,是使用 gt-plz-http-client
作为默认的请求客户端:
至少在我使用过程中,使用 gt-plz-http-client
后,再也没出现过你所说的莫名其妙阻塞的问题,而且请求的效率也大大提高。
当然,如果不是 url.el 引起的问题,而是代码哪个地方写得有问题,请不吝赐教。
谢谢!我做了更多的测试:
gt-youdao-dict-engine
从列表中移除,即使google-engine
出错,也不影响中途的正常输入。gt-request
和gt-parse
下断点,发现一路continue的话,偶尔会在有道的gt-parse
这里卡住。如果单步调试,可以看到一部分数据已经可以被解析到了。gt-parse
并不是处于竞争的状态。目前我还不能确定导致卡住的位置。按照您提供的信息,这个问题的出现与响应不及时有关。令人感到疑惑的是为什么只有youdao
会卡住整个emacs。我想问题也许不单纯是url
造成,而是它与eieio
之间的同步问题导致的。我对比了一下youdao
,google
和bing
的gt-parse
函数,它们的结构十分相似,youdao
的解析函数用一个很长的loop解析dom头,我想可能是这里获取某个键值时出现了问题。
我对这里的代码理解有限,这里或许可以做更细致的测试。
应该是 url.el 的问题,跟 parse 没关系。
比如这段代码,在我这里是同样是卡顿的:
(defun aaa ()
(interactive)
(url-retrieve
"https://dict.youdao.com/result?lang=en&word=retry"
(lambda (status)
(message "%s" (length (buffer-string))))))
另外麻烦请你测一下,如果使用 plz 作为请求客户端,有没有卡顿问题存在?
使用plz
没有产生卡顿,即使有短暂延迟,也不会卡住整个emacs。
这个问题似乎只在x86上存在,我在另一台arm64的机器上(archlinuxarm + xorg + emacs-29.3-3)没有遇到类似的问题。因此,这或许与当前emacs版本对make-network-process
的具体实现有关。plz
使用curl
,所以不会在这个函数里卡住。
我遇到问题的环境是archlinux_x86-64 + wayland + emacs-29.3-3,也许这个问题会随上游更新自然解决……
这问题已经存在很久了,等待 自然解决
估计很难……要不你去提交个 BUG?
我目前暂时没办法提供充分的测试。
描述:在糟糕的网络环境(比如挂http代理这种时延很大的情况)下,运行
gt-do-translate
目前会遇到卡死整个emacs的情况,按C-g
也没有反应。补充:根据观察应该是有道词典的问题,google卡住的时候仍然可以动,之前我一直用的是bing和google,印象中没有卡死过。
相应配置如下:
目前我用
async
包来规避这种情况,这样卡住的时候不会影响到编辑。我的建议是,即使没有异步支持,应该设法让
C-g
可以打断当前的查询,而不是让用户只能等到超时才能动。