Plugin overriding custom keymaps defined with bindkey

rbhanot4739 commented 2 weeks ago

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

[x] I have read through the README page
[x] I have the latest version of zsh-vi-mode
[x] 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

Create the zle widget and bindkey with minimal .zshrc
Source the plugin
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 commented 1 week ago

Can anyone please update on this ?

ristomatti commented 1 week ago

@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 commented 1 week ago

@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 commented 1 week ago

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 commented 1 week ago

@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 commented 1 week ago

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 commented 1 week ago

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

joeynguyen commented 1 week ago

@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!

jeffreytse / zsh-vi-mode