helm should not exit before end of update

[dwang20151005]

Expected behavior

If I do

(require 'cl)
(let ((prompt "prompt")
      (candidates (loop for i from 0 to 500000 collecting (format "foo bar baz %S" i)))
      (require-match nil))
  (completing-read "prompt" candidates require-match))

and type jjjjjk quickly, I would expect it to return what I typed but
instead it returns "foo bar baz 0".

This is inconvenient for me because I use helm everywhere (it's a great tool!), and sometimes I completing-read input for production systems.

Actual behavior from emacs-helm.sh if possible (See note at bottom)

See above.

Steps to reproduce (recipe)

See above.

Backtraces if some (M-x toggle-debug-on-error)

No error, just unexpected behavior.

Describe versions of helm, emacs, operating system etc.

helm-20170416.945
GNU Emacs 25.1.2 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars)
of 2016-09-20
CentOS 6
Linux igm-qws-u12112a 2.6.32-642.15.1.el6.x86_64 #1 SMP Fri Feb 24 14:31:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

IMPORTANT NOTE:

If you are using a Unix or GNU-Linux system there is no excuses
to not use emac-helm.sh to reproduce your bug in 99% of the cases.

[thierryvolpiatto]

dwang20151005 <notifications@github.com> writes:

Expected behavior If I do (require 'cl)

Use cl-lib instead.

(let ((prompt "prompt") (candidates (loop for i from 0 to 500000 collecting (format "foo bar baz %S" i)))

Use cl-loop

(require-match nil)) (completing-read "prompt" candidates require-match)) and type jjjjjk quickly, I would expect it to return what I typed but instead it returns "foo bar baz 0".

It is working, you just have to wait helm compute your request, `completing-read` is just an emacs function basically helmized without optimizations. However you can improve the performances by using directly `helm-comp-read` with :candidates-in-buffer t instead of completing-read, but :must-match is not already implemented so you can't exit with a non candidate.

…

-- Thierry Gpg Key fingerprint = 6CEC 7081 AB33 E251 4AB8 5FC2 28D1 7F53 59F2 9997

[thierryvolpiatto]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> and type jjjjjk quickly, I would expect it to return what I typed but > instead it returns "foo bar baz 0".

Try: (let ((candidates (cl-loop for i from 0 to 500000 collect (format "foo bar baz %S" i)))) (helm-comp-read "prompt: " candidates :candidates-in-buffer t))

…

-- Thierry Gpg Key fingerprint = 6CEC 7081 AB33 E251 4AB8 5FC2 28D1 7F53 59F2 9997

[dwang20151005]

I'm afraid I don't control the call site, so I cannot substitute helm-comp-read for completing-read. And I wouldn't, anyway, because not everyone who runs this code uses helm.

Also, I think you are treating this as primarily a performance issue, but I claim it is a matter of incorrect behavior. It's okay if helm gets very slow. It's a powerful, general package and I'm willing to pay for that. I wouldn't complain if I could type j j j k RET, wait however long, and get "jjjk". My complaint is that when there are enough candidates, helm returns something that does not match the keystrokes I typed before RET. Does that make sense?

[thierryvolpiatto]

dwang20151005 <notifications@github.com> writes:

I'm afraid I don't control the call site, so I cannot substitute helm-comp-read for completing-read. And I wouldn't, anyway, because not everyone who runs this code uses helm. Also, I think you are treating this as primarily a performance issue, but I claim it is a matter of incorrect behavior. It's okay if helm gets very slow. It's a powerful, general package and I'm willing to pay for that. I wouldn't complain if I could type j j j k RET, wait however long, and get "jjjk". My complaint is that when there are enough candidates, helm returns something that does not match the keystrokes I typed before RET.

No, all my tests return the coorect string, it is just that the example you gave is long to compute once you enter jjjk, you have to wait helm returns before hitting RET: When entering z in prompt helm returns z as expected: (completing-read "test: " '(a b c d e f g)) => "z"

…

-- Thierry Gpg Key fingerprint = 6CEC 7081 AB33 E251 4AB8 5FC2 28D1 7F53 59F2 9997

[thierryvolpiatto]

[dwang20151005]

Since you say I have to wait for helm to return before hitting RET, does that mean you can reproduce the behavior I reported where if I don't wait for helm before hitting RET, then helm returns the wrong thing?

If so, then I think we agree on the current behavior and only disagree on the desired behavior. I would prefer that the result not depend on the timing of the last keystroke.

[thierryvolpiatto]

Then when you press RET you have "jjjk" as expected.

[dwang20151005]

To say this another way: my mental model of helm is that it should consider each keystroke in order, and the result should be independent of the timing between keystrokes.

[thierryvolpiatto]

Since you say I have to wait for helm to return before hitting RET, does that mean you can reproduce >the behavior I reported where if I don't wait for helm before hitting RET, then helm returns the wrong >thing?

Of course, if you press RET immediately you endup with the first candidate.
He! you have in your example 500000 candidates, it emacs-lisp, it is slow you have to wait.

[jakemcarthur]

The bug dwang is trying to report is that this asynchronous behavior is pretty much never what he (or I) actually wants to happen. It would be easier to control your actions if f o o <wait for a while> RET behaved the same as f o o RET <wait for a while>.

[xiongtx]

If you hit RET, Helm immediately executes action on the currently selected candidate. If you haven't waited for Helm to filter candidates and put selection line on the one you want, you'll be executing action on the wrong candidate.

It takes time for Helm to interpret the keystrokes, filter the candidates, and put the selection line on the filtered candidate. Don't think there's a way around that.

[dwang20151005]

It sounds like a better mental model is that helm maintains a queue of keystrokes. Some keystrokes, like j j j k, are enqueued and processed in the order they are received. Other keystrokes, like RET, are processed immediately, even if there are still unprocessed keystrokes in the queue.

In that case, would it be hard to make RET go through the queue?

I'm just trying to avoid the behavior where I can type j j j k RET and depending on the timing of my keystrokes I get either foo bar baz 0 or jjjk. (Do you agree that this behavior is surprising?)

[thierryvolpiatto]

Oh! I understand now, it is a bug in helm--updating-p, I will fix soon.
Thanks.

[dwang20151005]

Thank you for writing helm!

[xiongtx]

Oh! I understand now, it is a bug in helm--updating-p

I stand corrected 😛.

[thierryvolpiatto]

Should now be fixed, you may not see the fix even when typing fast because I have now optimized completing-read (nearly instant update with your 500000 example).

[dwang20151005]

Works for me. And thanks for providing the emacs-helm.sh script. Makes testing so much easier.

[introom]

there should be an option to allow the old behavior of exiting helm when the update is not ready yet.

here is my use case, and I believe it's very general:
say I am working on the kernel code base with helm-gtags.

I type fast: skb_reserve and hit enter. However, helm prompts [Display not ready] and emacs gets stuck for seconds until the helm results are updated.

The thing is that, when I press enter, the highlighted entry is already what I want, even though the helm update is still in progress. It is not meaningful to wait for more seconds for the helm update.