Helm is hanging forever on Emacs 24.5.1 on Archlinux and others when loading tramp

[oppenlander]

Emacs hangs when a helm command is issued until the command is canceled (hitting C-g) in Emacs, version 24.5.1, on Archlinux.

I've also tried using the emacs-helm.sh script, with the same result: Emacs starts, than hangs until I issue C-g.

Installing through MELPA and through the git method in the README results in the same thing.

[thierryvolpiatto]

Don't think this is related to helm but to the emacs version builded by Archlinux.
I have heard about a similar issue on emacs-dev, with emacs on arch, it was not related to helm though.

[jeroentbt]

I ran M-x toggle-debug-on-error and my problem was fixed. Even after toggling it back off.
Even after a server restart. Did not try a reboot yet.

[thierryvolpiatto]

jeroen tiebout notifications@github.com writes:

I ran M-x toggle-debug-on-error and my problem was fixed. Even after toggling it back off.
Even after a server restart. Did not try a reboot yet.

Perhaps try to reinstall completely helm.

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[jeroentbt]

It was fixed, no change after reinstall.
@oppenlander can you verify that toggling debug-on-error, or reinstalling fixes the issue for you?

[oppenlander]

Toggling debug-on-error or reinstalling does not fix the issue for me.
Downgrading packages to use 24.4 works, but other applications that build against gnutils break unless they're also downgraded.
Building/using Emacs 25 works, but not all extensions work with 25.

[oppenlander]

I haven't completely solved the issue, but I have an update:

Helm is working, but is taking around 250 seconds for the initial load (I was killing it when it didn't load within 5s).
Going to look in to debugging this once I get some more free time.

[cig0]

FWIW, and I hope this isn't taken as noise, Helm works as expected on Emacs 24.5.1 on Fedora 21.

[bard]

Came across a similar problem and in my case it was caused by tramp, which Helm loads. See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20015 (fix: http://lists.gnu.org/archive/html/emacs-diffs/2015-03/msg00137.html)

[oppenlander]

@bard Thanks! Tramp timing out on connections seems to be the issue.
I temporarily solved my problem by setting ConenctTimeout=1 in ~/.ssh/config until I get a chance to figure out what it's actually timing out on.

[bard]

@oppenlander try ping host.does.not.exist (literally), that's the address tramp tries to connect to in order to get a failed connection. If you get anything other than "unknown host" then your ISP's DNS might be catching resolve failures and directing them at its own servers (like OpenDNS used to do, and like my ISP is doing).