Helm/Emacs becomes unresponsive during search

[smithzvk]

What I have noticed under GNU/Linux (Ubuntu 12.04 LTS 64bit) using Emacs 24.3.1 is that the helm interface freezes for a small break (about a second on my machine/Internet connection) after I have typed something but before any options show up in the search results.

I would expect that the Emacs interface would remain responsive while the search is performed and the output prepared.

This renders the interface still usable, but far from ideal as it pauses just enough to make it difficult to type.

Reproduction is easy for me. This happens every time I search for something on with helm-spotify.

If I were to guess what is happening, I would say that either helm is blocking all input while the web API request is made, request received, parsed, and the helm list is populated. I assume that this is not a slowness in Helm itself (this is my first time using helm) or the parsing, but rather simply the web API taking some time.

Perhaps an idle timer would fix things?

P.S. this is a pretty awesome toy.

[krisajenkins]

Hmm...this might be possible to improve. Both helm and the built-in url package support asynchronous operation, but in different ways that aren't straightforwardly compatible. I'll have to figure out how to wire them together. It sees like it'll be an interesting couple of things to learn, so I'll see what I can do when I get some time. But that probably won't be until next week...

Thanks for reporting it. :-)

[slackorama]

I think I'm seeing something similar on Ubuntu 14.04 with Emacs 24.3.1 but with a twist.

If I type too slowly (generally around the 3rd keypress) I get:

error in process sentinel: url-http-create-request: Transfer interrupted!
error in process sentinel: Transfer interrupted!

Seconded about this being pretty awesome.

[ankitsharmaks]

Any update on this issue?

[ankitsharmaks]

http://blog.johnregner.com/post/78877988910/fixing-helm-spotify
Bug fixed temporarily.