diff options
| author | zeertzjq <zeertzjq@outlook.com> | 2025-05-27 09:16:46 +0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-05-27 09:16:46 +0800 |
| commit | c4e52d604c9ac2fd47ab176ef0d1e4d72015485b (patch) | |
| tree | d387a785a3a86ed36fd8951e19f088c422d08866 /runtime/lua/vim/provider/python.lua | |
| parent | 8c5bd841edffd5b02b04220ab85ae0e3b7c81953 (diff) | |
| download | rneovim-c4e52d604c9ac2fd47ab176ef0d1e4d72015485b.tar.gz rneovim-c4e52d604c9ac2fd47ab176ef0d1e4d72015485b.tar.bz2 rneovim-c4e52d604c9ac2fd47ab176ef0d1e4d72015485b.zip | |
vim-patch:9.1.1413: spurious CursorHold triggered in GUI on startup (#34195)
Problem: spurious CursorHold triggered in GUI on startup
Solution: init global did_cursorhold flag to true
(Gary Johnson)
When Vim is started in GUI mode, the CursorHold autocommand event is
triggered 'updatetime' milliseconds later, even when the user has not
pressed a key. This is different from the behavior of Vim in terminal
mode, which does not trigger a CursorHold autocommand event at startup,
and contradicts the description of the CursorHold event in ":help
CursorHold", which states that the event is "[n]ot triggered until the
user has pressed a key".
The fix is to change the initial value of did_cursorhold from FALSE to
TRUE. While it is true that the CursorDone event has not been done yet
at startup, it should appear to have been done until the user presses
a key.
fixes vim/vim#17350
closes: vim/vim#17382
https://github.com/vim/vim/commit/318ff9c3627f595905064d11b0d66b63bfe89ff1
Co-authored-by: Gary Johnson <garyjohn@spocom.com>
Diffstat (limited to 'runtime/lua/vim/provider/python.lua')
0 files changed, 0 insertions, 0 deletions