"Waiting for process to die" and crashes when typing quickly on Gentoo

[chameco]

I'm getting Waiting for process to die... done in the minibuffer whenever I type a character within helm-system-packages on Gentoo (w/Portage), and when I type multiple characters in relatively quick succession (maybe within a second), the Helm buffer closes with no message. There isn't anything particularly nonstandard about my setup except syncing from git (eix works normally, etc.).

I couldn't find anything that might be causing this in my (admittedly cursory) overview of the source. As far as I can tell, helm-system-packages-refresh is only run at initialization and after commands are executed, and regardless runs without error when invoked manually.

Do you have any advice as to why this might be happening?

[Ambrevar]

Hmmm... No clue off the top of my head, sorry.
I really wonder why it would even been waiting for the process to die...

The current state of implementation is very good for Guix, pacman and xbps, and should be quite OK for dpkg. Sadly Portage hasn't be updated ever since I overhauled this package and I'm afraid it might be substantially broken.

It would not take much work to bring it up to speed, we only need someone with a Portage-based distro and a few hours on their hands. @chameco Interested? :)

[chameco]

Sure, if it's out-of-date then I'll gladly devote some time to fixing it. Give me a day or two and I'll submit a pull request.

[Ambrevar]

Thanks!
I'd suggest focusing on Pacman as a reference implementation. It's pretty polished and certainly the most complete.

What needs to be done:

• Backport the cache mechanism.
• Make sure it works over TRAMP.
• Drop the deprecated helpers (if any) and the portage-specific helpers/variables, if possible.

The code might not always be as clear as should be :( Let me know if there is any confusion.

[chameco]

I've pull-requested a quick fix for this in #24 - the precise issue was that the USE flag source was running portageq in the candidate transformer to determine whether the flag was enabled.

[Ambrevar]

Thanks for rooting it out! I'll review your pull request as soon as possible!

[Ambrevar]

Thank you for the pull request.
Now the most important bit is to replace the deprecated helpers. Feel free to give it a shot when you have time :)

[mullikine]

This also happens with helm-dash when typing and some other helms from memory. Helms that have high latency such as ones that make queries over the internet seem to be affected the most. Would this not be a bug in helm rather than packages that use helm?

[Ambrevar]

I believe this is a bug in upstream Helm indeed. I've experienced it myself in the past, but can't reproduce now. A friend of mine experiences it regularly. In both cases, this happens also in other Helms. The user configuration might have something to do with this.

[mullikine]

I have investigated it. Happy to understand the problem a little better now. In the function helm-get-candidates, inhibit-quit is set to non-nil if the source is an external process. But I'm guessing that some helm packages will hide this from helm and so to helm it must look like a regular function. The c function call-process will die if it gets the bell. I'm guessing that typing too quickly triggers the terminal bell, which is C-g. The real issue is figuring out how that bell is triggered and how to stop it from happening, but my guess is that it might not be so easy. I've just set inhibit-quit to t permanently in helm-get-candidates and I don't see the issue anymore.

[mullikine]

I have made a PR to upstream.
emacs-helm/helm#2418

[Ambrevar]

Thanks for your investigation!