[BUG] Visual mode highlight lingers after leaving visual mode

[jeffreytse]

General information

• Terminal program: tmux 3.5a (tmux-256color)
• Operating system: macOS 15.6.1 (24G90)
• ZSH framework: starship 1.22.1, zinit v3.13.1-11-gd05a5301 (darwin24.0_arm64)
• ZSH version: zsh 5.9 (arm64-apple-darwin24.0)
• ZVM version: zsh-vi-mode 0.12.0 (c3ea272, 2025-09-23 09:58:19 +0800)

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

I'm on version 0.12.0. I've noticed cases where the visual mode highlight lingers after leaving visual mode.

Reproduction steps

1. Type anything.
2. Type v, then h some times to select some characters.
3. Type either A or I.

zvm-317-lingering-visual-highlight.mp4

Expected behavior

Actual behavior: Insert mode is entered, the cursor is placed not where it should as per Vim and the visual highlight remains.
Expected behavior: Insert mode is entered, the cursor is placed where it should as per Vim and the visual highlight is gone.

[hernancerm]

I should have opened this as its own bug to begin with, thank you for creating the issue and addressing it so fast.

I tested the fix from c6bd7b7 and it works well, I no longer see the lingering visual highlight, however there is one minor issue: When following the reproduction steps and pressing A, the behavior in Vim (and Neovim) is leaving visual mode and entering insert mode as if pressing a from normal mode. However in ZVM the behavior is leaving visual mode and entering insert mode as if pressing A from normal mode.

Vim:

ZVM (after pressing A in visual mode the cursor ends up at the end of the line, not what happens in Vim):

Vim seems wrong lol. It makes more sense what ZVM does, but it's an inconsitency and I wanted to point it out.

[jeffreytse]

@hernancerm Yes, I'm also curious what you're talking about, as when pressing I, the cursor will go to the beginning of the line, however, pressing A isn't following the pattern going to the end of the line. I would like to leave this inconsistency for a while, and see how to align this from more users. BTW, thanks for your supporting to this project. : )

[hernancerm]

@jeffreytse I totally understand, I'm ok with leaving the inconsistency. It's nice knowing my reports/testing are appreciated :)

Focusing on the issue topic, after the fix from c6bd7b7 I did not find another case where the visual highlight lingers.

[jeffreytse]

This is intentional behavior in Vim’s design after my researching.

Vim has three different Visual modes:

1. v → charwise (character-based selection)
2. V → linewise (line-based selection)
3. Ctrl+v → blockwise (rectangular/block selection)

And I/A behave differently depending on the mode:

• I works in charwise, linewise, and blockwise modes — it always performs multi-line insert at the beginning of each selected line.
• A only performs multi-line insert in blockwise mode, because in that mode Vim knows exactly where the “end column” of the selection is.

In v or V mode, Vim cannot reliably determine the “end” of the selection for each line, so A only applies to the current line.

So this is not a bug, but rather a design choice for consistency:

• I → the beginning of a line/selection is always well-defined, so multi-line editing makes sense.
• A → the end of a selection is ambiguous in charwise/linewise mode, so only blockwise mode supports multi-line A.

[hernancerm]

I don't see documented behavior for v_A or V_A in the help files, I only see documented behavior for v_b_A (blockwise-visual append). However the mode in ZVM for the inconsistency is charwise-visual, and now that I notice, also linewise-visual. I don't understand where this information comes from, did I miss something in the help files?:

In v or V mode, Vim cannot reliably determine the “end” of the selection for each line, so A only applies to the current line. So this is not a bug, but rather a design choice for consistency

EDIT3: Although v_A and V_A are not documented, I agree with you that the reason likely is consistency with v_b_A.