fix: update last cursor on first CursorMoved #16698
Conversation
|
|
|
Oh, this is not entirely applicable to Vim, as Vim doesn't store last |
For whatever reason, these don't seem to have the same issue of immediately triggering. |
|
Added a test. @zeertzjq I personally think it is fine to address the issue CursorMoved independently of other autocommands (for which we don't have reported issues yet) as this fixes a weird quirk that affects gitgutter and other plugins. LMK what you think. |
Closes #16625 The first defined CursorMoved autocommand will immediately fire if the cursor has previously moved upon definition of the autocommand. Plugins add dummy autocommands such as: ```lua autocmd CursorMoved * execute '' ``` to avoid this behavior. Instead, when defining a new CursorHold autocommand, force update the last cursor position. See vim/vim#2053
|
Backport failed for Please cherry-pick the changes locally. git fetch origin release-0.6
git worktree add -d .worktree/backport-16698-to-release-0.6 origin/release-0.6
cd .worktree/backport-16698-to-release-0.6
git checkout -b backport-16698-to-release-0.6
ancref=$(git merge-base 95803f0e902278079e5876082465b1910c819947 1bf87ca88a2ee1e9cfc1f0b16128fca6b849f3e0)
git cherry-pick -x $ancref..1bf87ca88a2ee1e9cfc1f0b16128fca6b849f3e0 |
Closes #16625
Closes #12923
Supersedes #13867
The first defined CursorMoved autocommand will immediately
fire if the cursor has previously moved upon definition
of the autocommand.
Plugins add dummy autocommands such as:
to avoid this behavior.
Instead, when defining a new CursorHold autocommand, force
update the last cursor position.
See vim/vim#2053