Hi Eli, I tagged you back in this conversation because I may have fixed the issue :). Shane Mulligan How to contact me: 🇦🇺 00 61 421 641 250 🇳🇿 00 64 21 1462 759 <+64-21-1462-759> mullikine@gmail.com On Wed, May 19, 2021 at 6:48 PM Shane Mulligan wrote: > 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. > > ``` > 29c29,30 > < (let ((proc (get-buffer-process asynch-buffer))) > --- > > (let ((proc (get-buffer-process asynch-buffer)) > > (counter 0)) > 71a73,78 > > (with-local-quit > > (if (input-pending-p) > > (progn > > (setq counter (1+ counter)) > > (if (> counter 20) > > (keyboard-quit))))) > ``` > Shane Mulligan > > How to contact me: > 🇦🇺 00 61 421 641 250 > 🇳🇿 00 64 21 1462 759 <+64-21-1462-759> > mullikine@gmail.com > > > On Wed, May 19, 2021 at 11:32 AM Shane Mulligan > wrote: > >> My apologies. It was literally 5am when I wrote that. I think I have >> misunderstood `C-g` being generated with `quit-flag`. The bad behaviour is >> very clearly still happening. I will try to clarify this problem further by >> experimenting with it. I need to figure out why `while-no-input` suppresses >> the `quit` but merely setting `quit-flag` does not. Something indirect may >> be happening. >> >> Thank you all, >> Shane Mulligan >> >> How to contact me: >> 🇦🇺 00 61 421 641 250 >> 🇳🇿 00 64 21 1462 759 <+64-21-1462-759> >> mullikine@gmail.com >> >> >> On Wed, May 19, 2021 at 4:54 AM Eli Zaretskii wrote: >> >>> > From: Shane Mulligan >>> > Date: Wed, 19 May 2021 04:32:16 +1200 >>> > >>> > Thanks for looking into this so quickly. First some background on the >>> problem. I managed to work through >>> > this issue (https://github.com/emacs-helm/helm/issues/2417) with the >>> `emacs-helm` maintainer and we >>> > found what appears to be that the call to `accept-process-output` >>> inside of `url-retrieve-synchronously` will >>> > generate a `C-g` when there is pending input of any char. As far as I >>> can tell this is an issue only with >>> > terminal emacs. As I understand it, `inhibit-quit`, as used in >>> `accept-process-output` allows a `C-g` to be >>> > propagated outwards and handled and from what I can see by the >>> comments surrounding, >>> > >>> > ``` >>> > ;; accept-process-output returned nil, maybe because the >>> process >>> > ;; exited (and may have been replaced with another). If >>> we got >>> > ;; a quit, just stop. >>> > ``` >>> > >>> > the `C-g` in this case is expected. >>> > >>> > But I wonder if `C-g` was meant to be generated if the user was simply >>> mashing keys on the keyboard. In >>> > this case, the `C-g` emanating from `accept-process-output` was >>> bubbling up into `helm` and `helm` was >>> > treating it like an error. >>> > >>> > Here, you can see a quit being generated from the visual cue in the >>> minibuffer. >>> > https://asciinema.org/a/nAIB8Z1lGgZJqJg9Mt8YiNEM9 >>> > >>> > Here, I have added `while-no-input` and I no longer get the `quit`. >>> > https://asciinema.org/a/x9ELZhwDP1IUtmOz0M1cly42H >>> > >>> > However, as I test the addition of `while-no-input` with >>> `helm-google-suggest` (as above), though Quit is no >>> > longer being generated from mashing keys, the key input which would >>> have generated the `quit` is not >>> > immediately shown in `helm`. Instead, it only appears on the next key >>> press. So my implementation may not >>> > be perfect or complete. >>> > >>> > Finding the solution would make the minibuffer far less interrupted >>> while typing when >>> > `url-retrieve-synchronously` is used in the background. >>> > >>> > Thank you. >>> > >>> > Shane Mulligan >>> >>> Please in the future send your responses with the bug address, >>> 48500@debbugs.gnu.org, on the CC list, so that others will see your >>> detailed descriptions. I won't have time to take a good look into >>> that in the next few days, so it's good to make others aware of your >>> findings, because they might look into it meanwhile. >>> >>> Personally, I find it very strange that typing on the keyboard >>> produces C-g, it shouldn't happen, neither on a TTY nor on a GUI >>> display. >>> >>