I have done a write-up on this issue to clarify everything. https://mullikine.github.io/posts/fixing-googling-tooling-in-emacs/ 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:49 PM Shane Mulligan wrote: > 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. >>>> >>>