[vim/vim] feat(mouse): change Alt+click/drag to reset selection origin (PR #19957)

12 views
Skip to first unread message

Fletcher Gornick

unread,
Apr 11, 2026, 1:29:30 PMApr 11
to vim/vim, Subscribed

Hi! I previously proposed a similar change in Neovim (neovim/neovim#38943), but it wasn’t accepted there. I’m opening it here as it may be more appropriate for Vim itself.

Happy to adjust or drop this if it doesn’t align with Vim’s intended behavior. I'll leave another description below.

Problem

Alt+click/drag in Visual Block mode expands the selection relative to the furthest corner of the existing block, rather than the position where the drag started.

Solution

Update the selection anchor to the position of the initial click, so that dragging behaves consistently with standard mouse-based visual selections (left-click/drag).

The current behavioris from 6496966 for reference.

Before After
before.gif (view on web) after.gif (view on web)

You can view, comment on, or merge this pull request online at:

  https://github.com/vim/vim/pull/19957

Commit Summary

  • 780e276 feat(mouse): change Alt+click/drag to reset selection origin

File Changes

(4 files)

Patch Links:


Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/19957@github.com>

Fletcher Gornick

unread,
Apr 11, 2026, 1:48:18 PMApr 11
to vim/vim, Push

@fmgornick pushed 1 commit.

  • ab8d5cc feat(mouse): change Alt+click/drag to reset selection origin


View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/19957/before/445b79379d99ae966c290ab6ddf0807a84910865/after/ab8d5cc82e1f142d8472dddd0df9d88153e8b2ca@github.com>

Christian Brabandt

unread,
Apr 14, 2026, 2:30:40 PMApr 14
to vim/vim, Subscribed
chrisbra left a comment (vim/vim#19957)

I don't understand what is the reasoning behind changing this? Why now and why change only the Alt modifier? Note: that this might be a slightly backwards incompatible change. Also, wouldn't that be slightly inconsistent between the terminal and Gui versions of Vim?


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/19957/c4246232205@github.com>

Fletcher Gornick

unread,
Apr 15, 2026, 1:25:22 AMApr 15
to vim/vim, Subscribed
fmgornick left a comment (vim/vim#19957)

@chrisbra Yeah that's totally fair, backwards incompatibility is a real concern and I understand if that's a pass on its own.

The motivation is that regular visual-mode highlighting already works intuitively with left click: you click and drag, and it selects the area between the two points. Since alt-click+drag does blockwise selection, it feels like it should follow the same mental model: alt-click+drag fills the rectangular block region between the two points, rather than the current behavior. It's making the alt modifier consistent with how the non-alt case works.

On the terminal vs GUI question: alt-click is already an existing feature in terminal Vim, so this change isn't introducing a new inconsistency between the two, it's just modifying behavior that's already present in both codepaths.


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/19957/c4249456159@github.com>

Christian Brabandt

unread,
Apr 15, 2026, 2:02:47 PMApr 15
to vim/vim, Subscribed
chrisbra left a comment (vim/vim#19957)

So if I understand correctly, you are proposing that Alt-click will always restart a new block selection, instead of trying to extend the existing one, right? Also what I mean with the Gui version is, how does it behave in a GUI? Does Alt-click also re-sizes the block selection? Or does it do the restart block selection? Just want to make sure the behaviour beween a terminal Vim and in a GUI vim is consistent.


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/19957/c4254331130@github.com>

Christian Brabandt

unread,
May 18, 2026, 4:56:27 PM (9 hours ago) May 18
to vim/vim, Subscribed
chrisbra left a comment (vim/vim#19957)

let's not do it, sorry


Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/19957/c4482111260@github.com>

Christian Brabandt

unread,
May 18, 2026, 4:56:29 PM (9 hours ago) May 18
to vim/vim, Subscribed

Closed #19957.


Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/19957/issue_event/25677130016@github.com>

Reply all
Reply to author
Forward
0 new messages