diff options
| author | zeertzjq <zeertzjq@outlook.com> | 2026-07-01 20:59:25 +0800 |
|---|---|---|
| committer | zeertzjq <zeertzjq@outlook.com> | 2026-07-02 03:57:56 +0800 |
| commit | 826ca0ccfec949ee61d4f6baffd4e22e4ffc0076 (patch) | |
| tree | d5c79cfb36e6a7dfdb036fecccb89754d253f66b /test/functional/vimscript/executable_spec.lua | |
| parent | 5f47d7ac08326877ed9b4972a85872d44e3c1b72 (diff) | |
| download | rneovim-826ca0ccfec949ee61d4f6baffd4e22e4ffc0076.tar.gz rneovim-826ca0ccfec949ee61d4f6baffd4e22e4ffc0076.tar.bz2 rneovim-826ca0ccfec949ee61d4f6baffd4e22e4ffc0076.zip | |
vim-patch:9.2.0750: completion: 'autocompletedelay' deferral leaks state
Problem: After 'autocompletedelay' was made non-blocking, the deferred
popup can misbehave: a pending autocomplete survives leaving
Insert mode and then keeps waking the editor in Normal mode,
the deferral is recorded into registers while recording a
macro, the popup appears an extra 'updatetime' late when
'autocompletedelay' is larger and a CursorHoldI autocommand
exists, CursorHoldI can fire twice without an intervening
keypress, and an open balloon is dismissed (after v9.2.0739)
Solution: Treat the deferral like CursorHold: only keep it pending in
Insert mode and not while recording, with pending typeahead,
or when completion is already active; drop it when Insert mode
ends; measure the delay from when the user typed so a
CursorHold in between does not push the popup back; and do not
let the deferral re-enable CursorHoldI or dismiss the balloon.
(Hirohito Higashi).
closes: vim/vim#20669
https://github.com/vim/vim/commit/1f0f14bc2fbe278690c2b1510c9d0f3b5061020c
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Diffstat (limited to 'test/functional/vimscript/executable_spec.lua')
0 files changed, 0 insertions, 0 deletions