Describe the bug
When enter a window with text cursor at (1, 1) from another window with text cursor at (1, 1), CursorMoved would not be triggered. It also appear when both of their cursor are at the ending of the content.
To Reproduce
Detailed steps to reproduce the behavior:
vim --clean or gvim --clean.new or vnew to create several windows and type some words in them.autocmd! CursorMoved * echom 'Moved to ' . winnr().wincmd w or just use 'ctrl-w + w` to move cursor to other window.Environment (please complete the following information):
It also appear with GVim8.2 on Windows 7.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.![]()
Use any of these events:
BufLeave
WinLeave
WinEnter
BufEnter
There is nothing at :help CursorMoved which suggests that the event should be fired when focusing a different window. The help says that it should be fired when the cursor is moved while in Normal mode or Visual mode.
Use any of these events:
BufLeave WinLeave WinEnter BufEnterThere is nothing at
:help CursorMovedwhich suggests that the event should be fired when focusing a different window. The help says that it should be fired when the cursor is moved while in Normal mode or Visual mode.
In my understanding, moving from one window to another window is also a moving, do you agree it? And in general, say, cursor is not at the beginning or ending of the content, "CursorMoved" would be triggered.
In my understanding, moving from one window to another window is also a moving, do you agree it?
Not necessarily, and what I think doesn't matter; I'm not a dev. One could argue that it's anything listed at :help cursor-motions (from which :wincmd w is absent), and nothing else. Others could argue that :help window-move-cursor should be included too. In any case, as mentioned in the previous post, there are more accurate events to listen to if we want to execute arbitrary commands when focusing a different buffer/window.
I know where you are coming from, but for me, CursorMoved has always meant moving within a window and therefore it should not include moving between windows. It has been like this for a long time, I would prefer to not change that.
Closed #8493.
If you consider the output of getcurpos(), if it doesn't change then CursorMoved probably should not trigger.
I see no good reason to change the current behavior, even when it may seem the cursor moved to another window, this was not really the intention of this event.