search

emacs-helm / helm-system-packages

A Helm interface to the package manager of your operating system
GNU General Public License v3.0
106 stars 11 forks source link

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

Open chameco opened 6 years ago

chameco commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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:

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

chameco commented 6 years ago

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 commented 6 years ago

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

Ambrevar commented 6 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

I have made a PR to upstream. https://github.com/emacs-helm/helm/pull/2418

Ambrevar commented 3 years ago

Thanks for your investigation!