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

[Shane Mulligan]

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
	mullikine@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@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
	mullikine@gmail.com

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

> From: Shane Mulligan <mullikine@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?

url-retrieve-synchronously.el
Description: Text Data