Typing too quickly causes helm to show no candidates #173

Closed
dgutov opened this Issue Dec 11, 2012 · 11 comments

Comments

Projects
None yet
2 participants

dgutov commented Dec 11, 2012

...even after I slow down and/or delete the input string.

To reproduce:

  1. Start ./emacs-helm.sh
  2. Type M-x RET, then helm-recentf or helm-mini (because recentf performs initialization on the first run, which takes a bit of time).
  3. Hit RET and immediately press some buttons, for example typing a filename.
  4. Observe the lack of any recentf candidates.

I blame while-on-input, so the solution would probably be either to revert this change, or add an idle timer or something that would reschedule the computation of candidates.

I hit this basically each time I run Emacs, because I autoload helm and it takes a second to load the first time it's called, so I start typing before it computes the candidates.

GNU Emacs 24.2.90.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.6.0) of 2012-11-26

@thierryvolpiatto thierryvolpiatto added a commit that referenced this issue Dec 11, 2012

@thierryvolpiatto thierryvolpiatto Issue #173 Use no-delay-on-input in sources involved by helm-for-files.
* helm-bookmark.el: do it in all sources
* helm-buffers.el ( helm-c-source-buffers-list)
* helm-files.el: apply on sources involved by helm-for-files.
985c2d1
Owner

thierryvolpiatto commented Dec 11, 2012

Shoud be fixed, please try.
What do you mean by I "autoload helm" ?

dgutov commented Dec 11, 2012

Thanks, it works now. Looks like some third-party sources will also need to set this attribute. Mine did.

What do you mean by I "autoload helm"?

Just that it isn't loaded until it's used, so the input event queue naturally fills up while it's loading.
I actually require it in a function that then calls helm with specific arguments, but that's incidental.

dgutov closed this Dec 11, 2012

Owner

thierryvolpiatto commented Dec 11, 2012

Dmitry Gutov notifications@github.com writes:

Thanks, it works now. Looks like some third-party sources will also need to set this attribute. Mine did.
Note that async sources do not need this attribute, you have just to use
the attribute candidates-process' instead ofcandidates' (you will
have a warning to remind you to do it otherwise).

What do you mean by I "autoload helm"?

Just that it isn't loaded until it's used, so the input event queue naturally fills up while it's loading.
I actually require it in a function that then calls helm with specific arguments, but that's incidental.
Just calling (require 'helm-config) autoload all what's needed.


Reply to this email directly or view it on GitHub:
#173 (comment)

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

dgutov commented Dec 12, 2012

Just calling (require 'helm-config) autoload all what's needed.

I don't think that'll work: I'm only calling helm, but I'm using variables defined in sub-packages, like helm-c-source-buffers-list and helm-c-source-etags-select.

Owner

thierryvolpiatto commented Dec 12, 2012

Dmitry Gutov notifications@github.com writes:

Just calling (require 'helm-config) autoload all what's needed.

I don't think that'll work: I'm only calling helm, but I'm using
variables defined in sub-packages, like helm-c-source-buffers-list
and helm-c-source-etags-select.
So if you have your own commands that call helm'+ diverses sources, you can just turn onhelm-mode' which will load all what's needed.


Reply to this email directly or view it on GitHub:
#173 (comment)

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

dgutov commented Dec 12, 2012

On 12.12.2012 11:27, Thierry Volpiatto wrote:

Dmitry Gutov notifications@github.com writes:

Just calling (require 'helm-config) autoload all what's needed.

I don't think that'll work: I'm only calling helm, but I'm using
variables defined in sub-packages, like helm-c-source-buffers-list
and helm-c-source-etags-select.
So if you have your own commands that call helm'+ diverses sources, you can just turn onhelm-mode' which will load all what's needed.

Thanks, but I don't see how it can help. I use ido as completion
mechanism for the standard functions, partly because it's faster.

My own commands don't call `completing-read'.

Owner

thierryvolpiatto commented Dec 12, 2012

Dmitry Gutov notifications@github.com writes:

On 12.12.2012 11:27, Thierry Volpiatto wrote:

Dmitry Gutov notifications@github.com writes:

Just calling (require 'helm-config) autoload all what's needed.

I don't think that'll work: I'm only calling helm, but I'm using
variables defined in sub-packages, like helm-c-source-buffers-list
and helm-c-source-etags-select.
So if you have your own commands that call helm'+ diverses sources, you can just turn onhelm-mode' which will load all what's needed.

Thanks, but I don't see how it can help. I use ido as completion

Ok, but you can just use helm-mode to load all what's needed and disable
it afterward:
(helm-mode 1)
(helm-mode -1)

Just to avoid writing a lot of autoload/require stuff yourself in your
init file.

See also `helm-completing-read-handlers-alist', which allow to use ido
in some places instead of helm, but unfortunately it won't works
everywhere.

mechanism for the standard functions, partly because it's faster.
Probably, I have optimized only some of them.

My own commands don't call `completing-read'.


Reply to this email directly or view it on GitHub:
#173 (comment)

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

dgutov commented Dec 12, 2012

On 12.12.2012 12:06, Thierry Volpiatto wrote:

Dmitry Gutov notifications@github.com writes:

On 12.12.2012 11:27, Thierry Volpiatto wrote:

Dmitry Gutov notifications@github.com writes:

Just calling (require 'helm-config) autoload all what's needed.

I don't think that'll work: I'm only calling helm, but I'm using
variables defined in sub-packages, like helm-c-source-buffers-list
and helm-c-source-etags-select.
So if you have your own commands that call helm'+ diverses sources, you can just turn onhelm-mode' which will load all what's needed.

Thanks, but I don't see how it can help. I use ido as completion

Ok, but you can just use helm-mode to load all what's needed and disable
it afterward:
(helm-mode 1)
(helm-mode -1)

Sorry, how exactly will that help? From what I can see, calling
(helm-mode 1) will a) require helm and helm-files, b) set up
completing-read-function and read-file-name-function. And calling
(helm-mode -1) will undo b). I can just as well require helm and
helm-files myself, no?

Just to avoid writing a lot of autoload/require stuff yourself in your
init file.

See also `helm-completing-read-handlers-alist', which allow to use ido
in some places instead of helm, but unfortunately it won't works
everywhere.

mechanism for the standard functions, partly because it's faster.
Probably, I have optimized only some of them.

One of the reasons it's faster is that helm does the idle delay, and
helm-input-idle-delay's docstring warns against setting it to 0.

Owner

thierryvolpiatto commented Dec 12, 2012

Dmitry Gutov notifications@github.com writes:

Sorry, how exactly will that help? From what I can see, calling
(helm-mode 1) will a) require helm and helm-files, b) set up
completing-read-function and read-file-name-function. And calling
(helm-mode -1) will undo b). I can just as well require helm and
helm-files myself, no?
Probably yes if you don't need anything else.

Just to avoid writing a lot of autoload/require stuff yourself in your
init file.

See also `helm-completing-read-handlers-alist', which allow to use ido
in some places instead of helm, but unfortunately it won't works
everywhere.

mechanism for the standard functions, partly because it's faster.
Probably, I have optimized only some of them.

One of the reasons it's faster is that helm does the idle delay, and
helm-input-idle-delay's docstring warns against setting it to 0.
Not sure this is actually true as helm don't use anymore
`post-command-hook'.
So setting helm-input-idle-delay to 0 should work.
However it make sense to set helm-idle-delay to a value a value > 0 even
if it would work with 0.
I need to verify all this though and update the doc in consequence.


Reply to this email directly or view it on GitHub:
#173 (comment)

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

dgutov commented Dec 12, 2012

On 12.12.2012 12:52, Thierry Volpiatto wrote:

Dmitry Gutov notifications@github.com writes:

Sorry, how exactly will that help? From what I can see, calling
(helm-mode 1) will a) require helm and helm-files, b) set up
completing-read-function and read-file-name-function. And calling
(helm-mode -1) will undo b). I can just as well require helm and
helm-files myself, no?
Probably yes if you don't need anything else.

What if I also need helm-buffers, helm-tags, helm-imenu and
helm-match-plugin? Could you explain how it would load all that?

Owner

thierryvolpiatto commented Dec 12, 2012

Dmitry Gutov notifications@github.com writes:

On 12.12.2012 12:52, Thierry Volpiatto wrote:

Dmitry Gutov notifications@github.com writes:

Sorry, how exactly will that help? From what I can see, calling
(helm-mode 1) will a) require helm and helm-files, b) set up
completing-read-function and read-file-name-function. And calling
(helm-mode -1) will undo b). I can just as well require helm and
helm-files myself, no?
Probably yes if you don't need anything else.

What if I also need helm-buffers, helm-tags, helm-imenu and
helm-match-plugin? Could you explain how it would load all that?
Everything should be loaded as expected just using (require 'helm-config)
when using standard helm commands.
You can try with emacs-helm.sh.
For match plugin, just do (helm-match-plugin-mode 1).


Reply to this email directly or view it on GitHub:
#173 (comment)

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment