Plugins breaks if `zle -N zle-line-init` is called

[molovo]

Noticed this when working with oz/safe-paste and willghatch/zsh-hooks. If either of those plugins is sourced alongside zsh-history-substring-search then the history-substring-search-up and history-substring-search-down functions fail to work (both in normal usage, and when using zsh -f and only sourcing zsh-history-substring-search and the affected plugins).

Without either of those plugins it works fine. Both plugins register zle-line-init, and commenting out the line which registers it allows zsh-history-substring-search to work. Is there any way around this? It doesn't seem to matter which order the plugins are called in, the issue still occurs.

[sunaku]

I wonder if their zle-line-init ends up blocking the call to history-substring-search-up? It might be the case that the calls to this plugin's ZLE widgets aren't going through and they are in fact okay.

[squarefrog]

In case anyone else encounters this, you can rebind the keys after zle-line-init and you're able to use both history-substring-search and whatever requires the init function.

In my .zshrc I simply source keybindings.zsh at the end of the file to get both vi status and history search working.

[molovo]

Hmm. That might be it. I was already binding keys after zle-line-init, but I'm pulling keycodes out of the terminfo module, which reports up ($terminfo[kcuu1]) as ^[0A instead of ^[[A. Binding ^[[A manually mean up/down works with history-substring-search both before and after zle-line-init, but if I bind $terminfo[kcuu1] (^[0a), up/down only works before zle-line-init. I wonder why there's a distinction? In any case, I think this issue can be closed. Thanks @squarefrog for pointing me in the right direction.