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

Previous Next

Full log

View this message in rfc822 format

From: Shane Mulligan <mullikine <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, 48500 <at> debbugs.gnu.org
Subject: bug#48500: 28.0.50; url-retrieve-synchronously exits abnormally due to pending keyboard input from terminal
Date: Fri, 21 May 2021 11:35:27 +1200

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

Hey Eli,

A small update.
I found that when I used internet from a slower connection, the hang
returned, so I have a more robust workaround now. I simply abort the
function if there is a hang.

```
13c13,14
<   (let ((retrieval-done nil)
---
>   (let ((inhibit-quit t)
>         (retrieval-done nil)
17c18,19
<         (timed-out nil))
---
>         (timed-out nil)
>         (abort-hang nil))
29c31,32
<       (let ((proc (get-buffer-process asynch-buffer)))
---
>       (let ((proc (get-buffer-process asynch-buffer))
>             (counter 0))
38a42
>                     (not abort-hang)
72,74c76,87
<             (unless (or (with-local-quit
<                           (accept-process-output proc 1))
<                         (null proc))
---
>             (if (input-pending-p)
>                 (progn
>                   (setq counter (1+ counter))
>                   (if (> counter 20)
>                       (setq abort-hang t))))
>             ;; accept-process-output hangs without while-no-input; input
has
>             ;; nowhere to go. So avoid it.
>             (unless (or
>                      (while-no-input
>                        (with-local-quit
>                          (accept-process-output proc 0.1)))
>                      (null proc))
```
Shane Mulligan

How to contact me:
🇦🇺 00 61 421 641 250
🇳🇿 00 64 21 1462 759 <+64-21-1462-759>
mullikine <at> gmail.com
13c13,14
<   (let ((retrieval-done nil)
---
>   (let ((inhibit-quit t)
>         (retrieval-done nil)
17c18,19
<         (timed-out nil))
---
>         (timed-out nil)
>         (abort-hang nil))
29c31,32
<       (let ((proc (get-buffer-process asynch-buffer)))
---
>       (let ((proc (get-buffer-process asynch-buffer))
>             (counter 0))
38a42
>                     (not abort-hang)
72,74c76,87
<             (unless (or (with-local-quit
<                           (accept-process-output proc 1))
<                         (null proc))
---
>             (if (input-pending-p)
>                 (progn
>                   (setq counter (1+ counter))
>                   (if (> counter 20)
>                       (setq abort-hang t))))
>             ;; accept-process-output hangs without while-no-input; input
has
>             ;; nowhere to go. So avoid it.
>             (unless (or
>                      (while-no-input
>                        (with-local-quit
>                          (accept-process-output proc 0.1)))
>                      (null proc))

On Thu, May 20, 2021 at 1:12 AM Shane Mulligan <mullikine <at> gmail.com> wrote:

> 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)]

[url-retrieve-synchronously.el (text/x-emacs-lisp, attachment)]

Previous Next

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