GNU bug report logs - #48500
28.0.50; url-retrieve-synchronously exits abnormally due to pending keyboard input from terminal

Previous Next

Full log

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

From: Shane Mulligan <mullikine <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48500 <at> debbugs.gnu.org
Subject: Re: bug#48500: 28.0.50; url-retrieve-synchronously exits abnormally
 due to pending keyboard input from terminal
Date: Thu, 20 May 2021 01:12:10 +1200

[Message part 1 (text/plain, inline)]

I will do some further studies to see if I can find exactly how quit is
being generated.

Shane Mulligan

How to contact me:
🇦🇺 00 61 421 641 250
🇳🇿 00 64 21 1462 759 <+64-21-1462-759>
mullikine <at> gmail.com


On Wed, May 19, 2021 at 11:57 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Shane Mulligan <mullikine <at> gmail.com>
> > Date: Wed, 19 May 2021 18:48:09 +1200
> >
> > I may have resolved this issue with the following patch to
> `url-retrieve-synchronously`.
> > What this achieves is to trigger a `quit` in a controlled environment
> rather than allowing it to occur when
> > `accept-process-output` is run.
> > It's not always wanted to trigger a quit when `(input-pending-p)` is
> `t`. But I noticed from placing
> > `while-no-input` around `accept-process-output` to avoid the `quit` that
> `url-retrieve-synchronously` would
> > then hang but with the controlled `quit` happening beforehand,
> `accept-process-output` no longer needs
> > `while-no-input` around it. The end result is buttery smooth helm with
> no accidental `quit` from typing too
> > fast. I think this may have resulted in GUI helm faster too.
>
> Thanks, but what causes a quit in the first place?
>

[Message part 2 (text/html, inline)]

Previous Next

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