Plugin overriding custom keymaps defined with bindkey

[rbhanot4739]

General information

• Terminal program: WezTerm 20240812-215703-30345b36 (xterm-256color), Iterm2
• Operating system: macOS 14.7 (23H124)
• ZSH framework: None
• ZSH version: zsh 5.9 (x86_64-apple-darwin23.0)
• ZVM version: zsh-vi-mode 0.11.0

Basic examination

• I have read through the README page
• I have the latest version of zsh-vi-mode
• I have tested with another terminal program

Problem description

The plugin seems to override the custom keymaps defined with bindkey for custom zle widgets. Here is a minimal .zshrc

  cd ..
  zle reset-prompt
  zle accept-line
}

# Create the widget
zle -N cd_up_widget
bindkey '^U' cd_up_widget
source ~/.zsh/plugins/zsh-vi-mode/zsh-vi-mode.plugin.zsh

I have gone through the section in the readme that talks about strategies to deal with zvm overriding the keymaps and I followed the last option as mentioned below to workaround this issue

source ~/.zsh/plugins/zsh-vi-mode/zsh-vi-mode.plugin.zsh
cd_up_widget() {
  cd ..
  zle reset-prompt
  zle accept-line
}

function zvm_after_init() {
zle -N cd_up_widget
bindkey '^U' cd_up_widget

}

Although this works, I am not sure if this is the best way to deal with this because it slowly has started to bloat where I have to put a lot of stuff here.

function zvm_after_init() {
source <(fzf --zsh)
zle -N cd_up_widget
bindkey '^U' cd_up_widget
bindkey '^[[A' history-substring-search-up    # up
bindkey '^[[B' history-substring-search-down # down
}

So I am wondering if there is a better way to handle this.

Reproduction steps

1. Create the zle widget and bindkey with minimal .zshrc
2. Source the plugin
3. Try the keymap bound with bindkey

Expected behavior

Plugin should not override any keymaps which are not set explicitly by this plugin else it can break functionality of lot of other plugins or custom widgets user may have written on their own.

[rbhanot4739]

Can anyone please update on this ?

[ristomatti]

@rbhanot4739 I just installed this and noticed the same issue. For me changing the init mode to sourcing did the trick:

# Set this before loading the plugin
ZVM_INIT_MODE=sourcing

[rbhanot4739]

@ristomatti I tried this, however, setting ZVM_INIT_MODE=sourcing before loading the plugin, makes the plugin not load for me, i.e., I lose the plugin functionality.

[ristomatti]

TBH I didn't test further than pressing Esc to see if it takes to normal mode. It could've just been the result is set -o vi getting called from the plugin code. If you see that but the plugin specific features aren't loaded, I likely have the same issue.

[rbhanot4739]

@ristomatti I am not explicitly setting vi mode when using this plugin. If you are setting vi mode explicitly maybe that's why it's working for you, but setting init mode to sourcing is making the plugin functionality go away for me.

[ristomatti]

I'm not setting it explicitly, it gets enabled when the plugin loads. I'm now at the computer and could actually test this. It appears it does load properly with ZVM_INIT_MODE=sourcing on my setup. At least the cursor changes depending on mode, surround actions work and so does increment/decrement.

I'm using Antidote for plugin management.

[rbhanot4739]

Turns out I had an explicit bindkey -e in my .zshrc which was creating the issue for me.

[joeynguyen]

@rbhanot4739 I just installed this and noticed the same issue. For me changing the init mode to sourcing did the trick:

# Set this before loading the plugin
ZVM_INIT_MODE=sourcing

Thanks that fixed this issue for me as well!