Repeat action in normal mode chomps lines above

[scresante]

Environment information

• Terminal program: st
• Operating system: arch
• ZSH framework: no
• ZSH version: 5.9
• ZVM version: commit 9e909d0bdd
• tmux version: tmux-git 9694_3.2a.r405.g88d9a8fc-1

Basic examination

• [despite its length, yes] I have read through the README page
• [tested against a clean HEAD] I have the latest version of zsh-vi-mode
• [yes] I have tested with another terminal program

Problem description

using . (period) to repeat a command causes the lines above to disappear

Reproduction steps

1. put in a wordy line
2. enter normal mode, 0, dw
3. hit .
4. lines above get deleted

Expected behavior

Previous command repeats, lines above don't get chomped.

[scresante]

This isn't exactly related to the other line-chomping bug that exists. I've already corrected that in my repo at https://github.com/scresante/zsh-vi-mode/commit/1fd923de0aa6f9e4442d7c60b85c0e62589c5fb4 which has PR #180 .

Testing against that yields the same results as described above.

[scresante]

Testing in native bindkey -v, and . (period) works as expected there. Also, softmoth's plugin doesn't screw it up.

[ckirkos]

I see this problem also.

[Hubro]

Same here, super super super annoying. I often df<space> to delete one command line argument, then . to repeat it 4-5 times. Any time I hit ., 3 lines above the current line is deleted, which quickly completely clears the screen. Instead I have to hit df<space>df<space>df<space>df<space>df<space>, which works, but is a lot more work.

---

ZSH version 5.9 Starship version 1.12.0 zsh-vi-mode master branch (0e666689)

https://user-images.githubusercontent.com/597206/213866606-8feb6238-2496-40bf-9407-003672caabb3.mp4

[jeffreytse]

Hi @scresante

I think the latest commit #219 has settled your issue down, could you please have a try with the latest version?

Thanks & Regards

[jeffreytse]

Hi @Hubro

Firstly, thanks for your long time support, and I've tried my best to fix this kind of issue. I hope my latest commit def0f842b27c0b51f2f059d976fa24f4856839f2 and 2ca0cf64b2f8f4004ab329bb2e3f87a7bfd21f02 helpful to you. : )

Thanks & Regards

[Hubro]

@jeffreytse Of course, I still use this plugin every day :slightly_smiling_face:

The fix didn't work though, unfortunately. If I repeat a df<Space> command, above lines are still chomped. Also, if I spam <Esc>i<Esc>i it still sometimes eats above lines as well.

See recording:

https://github.com/jeffreytse/zsh-vi-mode/assets/597206/d3253b49-cc0d-4ffb-a7f3-2269f364e177

[jeffreytse]

Hi Hubro,

To solve this, as I can't reproduce it, I'd love to have a digging with you.

Thanks & Regards

[Hubro]

@jeffreytse Are you using Starship? My first guess is that the extra line breaks in every prompt is causing the issue.

Aside from that, my relevant zsh config is:

HISTFILE=~/.histfile
HISTSIZE=10000
SAVEHIST=10000
KEYTIMEOUT=1
WORDCHARS='*?_-.[]~=&;!#$%^(){}<>'

setopt SHARE_HISTORY nomatch notify

autoload -Uz compinit
compinit

autoload -U +X bashcompinit
bashcompinit

# Possible init script locations
ANTIGEN_INIT_SCRIPT=(
    "/usr/share/zsh/share/antigen.zsh"
    "/usr/share/zsh-antigen/antigen.zsh"
    "/usr/local/share/antigen/antigen.zsh"
)

for ANTIGEN_INIT_SCRIPT_PATH in "${ANTIGEN_INIT_SCRIPT[@]}"; do
    if [[ -f "$ANTIGEN_INIT_SCRIPT_PATH" ]]; then
        source "$ANTIGEN_INIT_SCRIPT_PATH"

        antigen bundle jeffreytse/zsh-vi-mode
        antigen bundle rupa/z
        antigen apply

        # Configure zsh-vi-mode
        zvm_after_init_commands+=('__apply_keybindings')
        ZVM_INSERT_MODE_CURSOR=$ZVM_CURSOR_BLINKING_BEAM
        ZVM_NORMAL_MODE_CURSOR=$ZVM_CURSOR_BLOCK
        ZVM_LINE_INIT_MODE=$ZVM_MODE_INSERT
        ZVM_CURSOR_STYLE_ENABLED=true
        #ZVM_INSERT_MODE_CURSOR=$ZVM_CURSOR_BLINKING_BLOCK
        #ZVM_NORMAL_MODE_CURSOR=$ZVM_CURSOR_BLOCK

        break
    fi
done

unset ANTIGEN_INIT_SCRIPT
unset ANTIGEN_INIT_SCRIPT_PATH

function __apply_keybindings() {
    # Re-applies FZF keybindings
    if [[ -f "/usr/share/fzf/key-bindings.zsh" ]]; then
        source "/usr/share/fzf/key-bindings.zsh"
    elif [[ -f "/usr/local/Cellar/fzf/0.39.0/shell/key-bindings.zsh" ]]; then
        source "/usr/local/Cellar/fzf/0.39.0/shell/key-bindings.zsh"
    fi

    zvm_define_widget __up_one_dir
    zvm_bindkey viins '^U' __up_one_dir
}

# ZVM widget to go up one directory (cd ..)
function __up_one_dir() {
    BUFFER="cd .."
    zle accept-line
}

# Executed automatically by zsh-vi-mode for setting up keybindings
function zvm_after_lazy_keybindings() {

}

# Starship
if which starship &>/dev/null; then
    eval "$(starship init zsh)"
fi

My Starship config is:

command_timeout = 2000

format = """\
    $username\
    $hostname\
    $kubernetes\
    $directory\
    $git_branch\
    $git_state\
    $git_status\
    $package\
    $dotnet\
    $golang\
    $java\
    $nodejs\
    $python\
    $ruby\
    $rust\
    $custom\
    $nix_shell\
    $conda\
    $memory_usage\
    $aws\
    $env_var\
    $cmd_duration\
    $line_break\
    $jobs\
    $battery\
    $time\
    $character\
"""

[character]
#success_symbol = "[➜](bold green)"
success_symbol = "[󰁔](bold green)"
vicmd_symbol = ""
#vicmd_symbol = " ∷"
error_symbol = "[󰁔](bold red)"

[cmd_duration]
#disabled = true
#show_notifications = true
#min_time_to_notify = 30

[python]
pyenv_version_name = true

[nix_shell]
format = "[\\[$name\\]]($style) "

[custom.direnv]
format = "[\\[direnv\\]]($style) "
style = "fg:yellow dimmed"
when = "env | grep -E '^DIRENV_FILE='"

If you're unable to reproduce the issue with this config, I'll contact you by email and we can troubleshoot further if you want.

[jeffreytse]

After further digging, the minimal reproduced steps as below:

• Open a new interactive ZSH without configuration zsh -d -f -i.
• Sourcing zsh-vi-mode.zsh and eval "$(starship init zsh)".
• Type echo foo bar zoo and switch to normal mode by hit <ESC>.
• Type 0 going to the head and then type df<space>.
• Hit . to repeat the last command.

The above line will be eaten as we expect.

[jeffreytse]

This issue is related to #124 as well.