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

Previous Next

Full log

Message #59 received at 34763 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 34763 <at> debbugs.gnu.org
Subject: Re: bug#34763: 27.0.50; url-retrieve-synchronously misbehaves inside
 eldoc-documentation-function
Date: Thu, 04 Apr 2019 17:36:30 +0300

> Cc: 34763 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Thu, 4 Apr 2019 16:29:24 +0300
> 
> On 04.04.2019 16:04, Eli Zaretskii wrote:
> > If that's the intent, why does it need to explicitly quit in Lisp?
> > Just letting the code leave the form where inhibit-quit is non-nil
> > will let Emacs quit at the first opportunity, with no need for any
> > Lisp code for that.
> 
> Because accept-process-output doesn't abort on user input?

It doesn't?  Are you sure?  Or are you talking about calling
accept-process-output with inhibit-quit non-nil?

> And url-retrieve-synchronously calls it with 1 second timeout (which
> is a fairly long wait).

That could be dealt with by making the timeout shorter.

> 2. I wonder if there are cases where some part of the asynchronous code 
> takes too long, where it should be allowed to be aborted by the user 
> right away. Meaning when url-retrieve is used, not 
> url-retrieve-synchronously.

I always thought that C-g aborts accept-process-output.

Previous Next

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