Completions intermittently fail

[spacebat]

I keep trying to use helm but a few minutes into a session, start seeing the following behaviour. When completing with helm, the number of completion candidates drops to zero. Right now:
M-x eldoc-
gives: turn-on-eldoc-mode and eldoc-mode

M-x eldoc-m
M-x eldoc-mo
gives nothing at all

M-x eldoc-mod
gives: turn-on-eldoc-mode and eldoc-mode

M-x eldoc-mode
gives nothing at all

At that point, helm is worse than no completion at all, since I've typed something valid but pressing enter gets me nowhere.

A few minutes later, eldoc-mode completes just fine but some other completion exhibits similar behaviour in helm.

I've tried helm from melpa and directly from github, version 1.7.0 and HEAD, updated my emacs (currently 24.5.50.1), tried running it via emacs -Q and loading helm from the git repo manually, but the problem persists.

Its perplexing because some people are swear by helm and never seem to experience this, but this would be about the 4th time I've tried helm over the last few years and found it promising but ultimately unusable due to problems like this, across various combinations of versions of helm and emacs.

[tuhdo]

Use helm-M-x. It is written in the very top Basic Usage section. The stock M-x is a different command and is useless when helm-mode is enabled. You may want to look at my Helm guide.

[thierryvolpiatto]

Andrew Kirkpatrick notifications@github.com writes:

I keep trying to use helm but a few minutes into a session, start
seeing the following behaviour. When completing with helm, the number
of completion candidates drops
to zero.

I don't see why this would happen.

Right now: M-x eldoc- gives: turn-on-eldoc-mode and eldoc-mode

M-x eldoc-m
M-x eldoc-mo
gives nothing at all

M-x eldoc-mod
gives: turn-on-eldoc-mode and eldoc-mode

M-x eldoc-mode
gives nothing at all

A few minutes later, eldoc-mode completes just fine but some other
completion exhibits similar behaviour in helm.

This is not reproductible, tried on emacs-24.5 and emacs-25.

I've tried helm from melpa and directly from github, version 1.7.0 and
HEAD, updated my emacs (currently 24.5.50.1), tried running it via
emacs -Q and loading helm from the git repo manually, but the problem
persists.

How are you installing ("loading") helm ?
Look at the readme on how to install helm, or run the script
"emacs-helm.sh" from the helm repo.

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

[thierryvolpiatto]

Tu Do notifications@github.com writes:

Use helm-M-x.

Anyway the regular execute-extended-command is working fine too and
this bug is not reproductible with both commands.

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

[spacebat]

I wasn't using helm-M-x, I guess because execute-extended-command did appear to function, but after a while I'd start seeing the missing completions. The basic setup mentions helm-M-x but then goes on to say you can just put (helm-mode 1) in init.el and enjoy helm under M-x and elsewhere. I thought that it wasn't just under M-x that the completions were failing, but I'll give helm-M-x a go for a few days and see how it works out.

I've loaded helm via package.el and alternately loaded from the git repo via add-to-path and require. I've not tried the shell script yet.

Thanks for the prompt responses.

[tuhdo]

Anyway the regular execute-extended-command is working fine too and
this bug is not reproductible with both commands.

Ah yes it's usable but it may annoy users because there was not real sorting i.e. if you try M-x list-package, it gives something else instead of list-package. I had to tell the user to replace with helm-M-x because it gave him bad impression with Helm. I think it's better for helm-mode to remap execute-extended-command with helm-M-x and restore it back when helm-mode disabled. Same for switch-to-buffer.

[thierryvolpiatto]

Tu Do notifications@github.com writes:

Anyway the regular execute-extended-command is working fine too and
this bug is not reproductible with both commands.

Ah yes it's usable but it may annoy users because there was not real
sorting i.e. if you try M-x list-package, it gives something else
instead of list-package. I had to tell the user to replace with
helm-M-x because it gave him bad impression with Helm.

Maybe, but this is unrelated with the actual bug, which is a problem
with "completing against obarray", we don't care here what is the best
command, helm-M-x or the regular execute-extended-command, this is not
the subject. So please focus on the actual problem.

@spacebat Did you try recompiling your emacs with "make bootstrap" ?

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

[spacebat]

Using helm-M-x, I am running into the problem again. Its like the completion cache, if there is one, gradually becomes broken and only sometimes populates. I think it is always either the correct set of completions or empty.

I've been using emacs in manjaro linux, a flavour of arch, and it looks like its package build recipe doesn't use make bootstrap. I'll build emacs manually to try bootstrap.

[thierryvolpiatto]

Andrew Kirkpatrick notifications@github.com writes:

Using helm-M-x, I am running into the problem again.

Yes, there is no reasons helm-M-x works better than the old M-x you used
(execute-exended-command helmized) the COLLECTION is computed more or
less in the same way.
I think the bug comes from emacs itself and is not related to helm.

Its like the completion cache, if there is one,

What are you calling the completion cache ?

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

[spacebat]

I'm starting to debug it now; I guess by completion cache I'd mean the candidates variables in helm-comp-read. However it is definitely populated and remains so even when I get no results. I'll let you know what I find.

[michael-heerdegen]

@spacebat Do you get any messages in the Messages buffer when the problem happens? Then setting debug-on-error to t might give you a backtrace.

[spacebat]

No messages, no errors. Setting debug-on-error doesn't trigger the debugger when the problem occurs. I've enabled helm debug logging but there's a lot of output and the cause isn't clear yet.

[spacebat]

I've built a fresh emacs from savanna git master starting with make bootstrap, using helm from github as of may 19 and still get the problem. Next up I'll try that shell script installation method for helm.
GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.3)

[michael-heerdegen]

Does the problem happen for you with emacs-helm.sh btw? Or could it be related to your setup?

I don't think that trying more installation methods is necessary, as long as you are sure that you had installed it correctly.

[michael-heerdegen]

Also (setq debug-on-signal t) might help debugging.

Or (setq helm-debug t), and have a look at every output between "Start updating" and "end update". Especially, when the problem occurs, is "end update" printed at all? If it is, does the output in between look different?

[spacebat]

It takes a while to test; it doesn't happen at first, which is why I was thinking some kind of cache/state corruption might be the cause. I just updated helm trunk and using my normal config it started happening again, debug-on-signal is catching nothing. The output of helm-debug would be easier to understand if the keystrokes were logged - because sometimes it works, sometimes it doesn't and its hard to tease the cases apart in the log. Also I've had emacs crash twice this morning while helm-debug was active, probably because I've gone to the bleeding edge in search of a fix.

[thierryvolpiatto]

If you had crash, perhaps you should run your emacs in GDB. Isn't this bug related to #1000 ?

[spacebat]

Trying it under GDB now, though I doubt its related since I wasn't getting crashes until I went to the most recent emacs commit from savannah. It may not be related to #1000 because I'm no longer running emacs packaged by Arch but the problem persists. Thanks for the help.

[thierryvolpiatto]

Andrew Kirkpatrick notifications@github.com writes:

Trying it under GDB now, though I doubt its related since I wasn't
getting crashes until I went to the most recent emacs commit from
savannah. It may not be related to #1000 because I'm no longer running
emacs packaged by Arch but the problem persists. Thanks for the help.

I remember that we have add a similar problem (see #967).
But it was fixed in emacs.
I just reference it here for memory.

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