Support vi linewise region causes: unhandled ZLE widget

[mafredri]

With the latest commit (d13da0c) on master, I started seeing the following errors:

zsh-syntax-highlighting: unhandled ZLE widget 'history-substring-search-up'
zsh-syntax-highlighting: unhandled ZLE widget 'history-substring-search-down'

Looking at the commit I don't see anything obvious, but checking out the previous makes the error disappear.

[danielshahaf]

Could you please show the output of print -r -- $ZSH_VERSION $ZSH_PATCHLEVEL ${widgets[history-substring-search-up]} ${widgets[history-substring-search-down]}? Can you bisect your zshrc to the smallest one that reproduces the problem? Do you use bindkey -v or bindkey -e?

[danielshahaf]

Crossreferencing #267 which that commit (d13da0c) fixed.

[danielshahaf]

The error message is printed by _zsh_highlight_bind_widgets, which is invoked once at the start, before the the function that d13da0c touches is invoked for the first time (and isn't invoked again subsequently). Odd...

[ninrod]

is this history-substring-search-up a standard zle widget or is it comming from another plugin?

[mafredri]

I only see the error once when my .zshrc is loaded, and whilst trying to create a minimum repro it seems that it only happens when bindkey references history-substring-search-* before the plugin is loaded.

Here's the output @danielshahaf:

5.2 zsh-5.2-0-gc86c20a user:history-substring-search-up user:history-substring-search-down

Minimum repro:

zmodload zsh/terminfo
bindkey $terminfo[kcuu1] history-substring-search-up
bindkey $terminfo[kcud1] history-substring-search-down

source $ZSH/modules/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh
source $ZSH/modules/zsh-history-substring-search/zsh-history-substring-search.zsh

Of course, moving the bindkey statements after the sourceing makes the error disappear. As per zsh-history-substring-search#usage it should be sourced after zsh-syntax-highlighting, which is why the order is as it is above. I suppose d13da0c caused bindkey widgets to be evaluated at an earlier phase?

[danielshahaf]

Thanks for the minimal reproduction. I can reproduce that error message with just:

% zmodload zsh/terminfo
% bindkey $terminfo[kcuu1] history-substring-search-up
% source zsh-syntax-highlighting.zsh
zsh-syntax-highlighting: unhandled ZLE widget 'history-substring-search-up'

However, unlike you, I can reproduce it both with d13da0c and with its predecessor b9112ae.

I'm afraid that's working as designed: z-sy-h currently works by rebinding all widgets. When it encounters an undefined widget, it can't wrap that widget, so it warns. (Consequently, invoking that widget — in this case, pressing ↑ or ↓ — will not recompute highlighting.)

As to a workaround, moving the bindkeys below the source zsh-syntax-highlighting.zsh line (as you wrote) is probably the right thing: that will sidestep the warning, and shouldn't affect the interaction of z-sy-h and z-h-s-s in any way. In the longer term, this is the kind of issue that should be entirely prevented by the fix to #245 (expected to be available in z-sy-h 0.5.0 under zsh 5.3)... except that z-h-s-s violates layering (zsh-users/zsh-history-substring-search#58) so I am not going to try and guess how z-h-s-s would interact with z-sy-h-post-#245.

I suppose d13da0c caused bindkey widgets to be evaluated at an earlier phase?

No, it didn't. _zsh_highlight_bind_widgets runs once at the time of the source zsh-syntax-highlighting.zsh; _zsh_highlight runs at every keypress. d13da0c simply changed the computation of the start and end offsets of the region highlighting.

I can't think of any reason your reproduction script would behave differently with d13da0c compared to b9112ae (its predecessor).

[mafredri]

Testing again it seems that b9112ae is actually the offending commit, if I rebase without it, the error goes away. I could've sworn I tested with it before opening up this issue, sorry about that.

Anyway, thanks for looking in to this, I'll probably just settle for moving my bindkey statements.

[danielshahaf]

Testing again it seems that b9112ae is actually the offending commit, if I rebase without it, the error goes away.

/cc @m0vie

I'm not sure whether this difference between zle -la and ${(k)widgets} is intentional; might be worth asking zsh upstream.

Thanks for reporting this.

[danielshahaf]

I'm not sure whether this difference between zle -la and ${(k)widgets} is intentional; might be worth asking zsh upstream.

Done: users/21729

[danielshahaf]

Upstream says this difference is intentional.

I suppose this may affect other configurations / widgets, but for the reasons given above, I think warning here is appropriate... so I'm closing this, but we can revisit this in the future if it turns out to have wider repercussions. Thanks again for the report!

[mafredri]

Sounds good, thanks for investigating!