GNU bug report logs - #34763
27.0.50; url-retrieve-synchronously misbehaves inside eldoc-documentation-function

Previous Next

Package: emacs;

Reported by: Dmitry Gutov <dgutov <at> yandex.ru>

Date: Tue, 5 Mar 2019 21:35:01 UTC

Severity: normal

Found in version 27.0.50

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34763 <at> debbugs.gnu.org
Subject: bug#34763: 27.0.50; url-retrieve-synchronously misbehaves inside eldoc-documentation-function
Date: Thu, 4 Apr 2019 02:37:49 +0300
On 15.03.2019 17:49, Eli Zaretskii wrote:

> The code in the functions that react to quit-flag being non-nil should
> be audited.  They don't look clean to me, FWIW, and we don't generally
> do such things from Lisp, we normally quit on the C level.  Maybe this
> whole sub-feature, whereby we show a message for interrupted
> transfers, should be rethought.

Apparently the idea is to handle quits, including contexts where 
inhibit-quit is t (947612be2c71d2478179694e8dfa538b9e8e07c1).

So url-retrieve-synchronously uses with-local-quit around 
accept-process-output, and I guess the idea was to handle quits inside 
debugging output calls.

So url-http-debug also does the job of clearing the sentinel and the 
filter of the connection's process.

But maybe that's not enough: it doesn't kill the process and/or remove 
it from url-http-open-connections. (I'm guessing 
url-http-mark-connection-as-free would normally be called later if the 
sentinel wasn't removed).

I'm not quite clear on how error handling should work here anyway. 
Asynchronous code is tricky that way.




This bug report was last modified 6 years and 3 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.