Zsh-autocomplete: First prompt not working for Zinit lazy load

[weilbith]

Environment

• Zsh version: zsh 5.8 (x86_64-pc-linux-gnu)
• zsh-autocomplete version: 85e23dbf6e3a2e34ff91969f0bb3f99b21e80e97

Does the bug occur without config files?

• [ ] Yes
• [X] No

Which combination of config causes the bug to appear?

source /usr/share/zsh/scripts/zinit/zinit.zsh

autoload -Uz _zinit
(( ${+_comps} )) && _comps[zinit]=_zinit

zinit wait lucid light-mode \
  atinit"zstyle ':autocomplete:*' groups 'always'" \
  atinit"zstyle ':autocomplete:(slash|space):*' magic 'off'" \
  for marlonrichert/zsh-autocomplete

Steps to reproduce

1. Use zinit as plugin manager
2. Alternate the given configuration with and without wait keyword

Expected behavior

Autocomplete plugin works on first prompt after it has been loaded. Also in lazy loading mode.

Actual behavior

Autocomplete plugin works only from the second prompt on. Only without wait this works in first prompt.

---

Soooo. after this long template: I guess there must be some function that I need to call manually when the plugin got loaded. So for example for the autosuggestion you do something like this (taken from zinit docs):

zinit wait lucid light-mode \
     atload"_zsh_autosuggest_start" \
     for zsh-users/zsh-autosuggestions

So is there maybe something like this? For the fast syntax highlight plugin it is atinit"zicompinit; zicdreplay".

[weilbith]

PS: At the same time I now have issues with fast-syntax-highlighting. I was able to reduce it exactly just the case when both plugins are loaded. Then I get this message: zsh-syntax-highlighting: unhandled ZLE widget '^[u^[u^@' But just when I load it lazy as well. In detail like that:

zinit wait lucid light-mode \
  atinit"ZINIT[COMPINIT_OPTS]=-C; zicompinit; zicdreplay" \
  for zdharma/fast-syntax-highlighting

Do you have an idea what this comes from? Should/do I need to open an issue there?

[marlonrichert]

What you're seeing is a side-effect of using zinit wait: zsh-autocomplete adds several hooks that run before the first prompt. However, zinit wait delays zsh-autocomplete initialization until after the first prompt, meaning it won't get to add its hooks until _after_ the first prompt. This causes the hooks to not trigger until the next prompt. There's nothing zsh-autocomplete can do about that. You'll just have to use it without zinit wait.

However, there's a much easier way to reduce your Zsh startup time: Just use Znap as your plugin manager and use its znap prompt command to make your prompt appear instantly. 😁

PS: zstyle ':autocomplete:(slash|space):*' magic 'off' doesn't do anything anymore. I've removed the autocorrection feature. Also, you don't need to put zstyle commands into atinit. As long as you run them before sourcing the plugin that uses them, you should be fine.

[weilbith]

What you're seeing is a side-effect of using zinit wait: zsh-autocomplete adds several hooks that run before the first prompt. However, zinit wait delays zsh-autocomplete initialization until after the first prompt, meaning it won't get to add its hooks until after the first prompt. This causes the hooks to not trigger until the next prompt. There's nothing zsh-autocomplete can do about that. You'll just have to use it without zinit wait.

Okay so since autocomplete should load quite fast I guess is is fine to not use the lazy loading. I thought there is maybe a function that registers all the hooks that could be called manually after finished loading.

However, there's a much easier way to reduce your Zsh startup time: Just use Znap as your plugin manager and use its znap prompt command to make your prompt appear instantly.

I already saw that you introduced your own plugin manager. I must admit that I'm tired of switching/reading about zsh plugin managers. I think now I'm on a fast one that is incredibly powerful. Probably too powerful and I wont need 90% of it. But after all I have the options, it works pretty well (well, I opened an issue here...) and appears more future stable to me. So I don't "need" to switch another time soon. But that is personal taste and as I said I'm pretty annoyed atm.

PS: zstyle ':autocomplete:(slash|space):*' magic 'off' doesn't do anything anymore. I've removed the autocorrection feature. Also, you don't need to put zstyle commands into atinit. As long as you run them before sourcing the plugin that uses them, you should be fine.

Thanks for the hint. I just adopted to the recent refactorings of you to make it work again as it was before. I should read the docs from scratch to get the recent features and changes properly set up.
Which reminds of that on the new version you are giving visual hints which keys to use to jump to the next group or open an too long list of candidates. I think those hints do not take the set options into account (e.g. I don't use the arrow down key, but it gets still suggested and does not work for me). But that is a standalone "issue".

[weilbith]

Ah, anything to the correlation wit the fast syntax highlighting plugin?

[marlonrichert]

Ah, that looks like a bug indeed. Thanks for finding it. I'll fix it.

[marlonrichert]

I already saw that you introduced your own plugin manager. I must admit that I'm tired of switching/reading about zsh plugin managers. I think now I'm on a fast one that is incredibly powerful. Probably too powerful and I wont need 90% of it. But after all I have the options, it works pretty well (well, I opened an issue here...) and appears more future stable to me. So I don't "need" to switch another time soon. But that is personal taste and as I said I'm pretty annoyed atm.

It's funny that you say that: I wrote Znap exactly because I got annoyed with Zinit. 😁 Like you state, Zinit does much more stuff than you'll ever need. That by itself doesn't sound so bad, but I discovered Zinit actually does a bunch of stuff _without asking_ and can thus unknowingly alter the behavior of your plugins or even slow down your shell at runtime. Couple that with a really strange syntax and I just got enough of it.

[marlonrichert]

I thought there is maybe a function that registers all the hooks that could be called manually after finished loading.

There currently isn't, but I could add one.