- Replace exists('l:startcol') with a boolean flag in s:on_change()
- Avoid full asyncomplete#context() in textchangedp change detection; use lightweight line()/col()/getline() instead
- Build context dict directly from local vars instead of intermediate dict lookups
- Skip s:strip_pair_characters() call when base doesn't start with a pair character
- Bulk-append items when base is empty instead of per-item add
- Use add() instead of += [val] for startcols list building
- Fix redundant getcurpos() call in timer.vim s:maybe_notify_on_change()
- Early return in asyncomplete#log() when log file is empty
Prevent errors processing textchanged that don't come from insert mode.
When using asyncomplete with vim-ripple, I get these errors:
Error detected while processing TextChangedI Autocommands for "*"..function <SNR>43_on_text_changed_i[1]..<SNR>43_maybe_notify_on_change:
line 15:
E121: Undefined variable: s:previous_context
Error detected while processing InsertLeave Autocommands for "*"..function <SNR>43_on_insert_leave:
line 1:
E108: No such variable: "s:previous_context"
ripple uses :startinsert, but I can't replicate the error with just that
command. Not sure what's wrong, but this seems like a reasonable fix.
Plugins
=======
asyncomplete
ripple
Repro
=====
Hit CR when on a blank line:
gvim +"RippleCreate lua"
down arrow
CR
* Remove "skip popup" related logic
* Fix matches not getting cleared
Before this commit we don't clear the matches when the text
under the cursor is no longer suitable for completion. This
causes e.g. removing everything using <BS> does not close
the completion menu.
* Allow closing popup menu
Closing popup menu calls completion itself, making it
impossible to be successful.
We used to have a "skip popup" logic to fix this. It was
removed 2 commits ago for being too confusing.
To fix this a check is adapted to make sure that completion
is only called when the completion context has changed.
Since closing popup menu does not change the completion
context, it no longer calls completion, and therefore can
succeed.
Previously this check lets us not complete when we move to a
different line we are in insert mode, through for example
<CR> or <BS>, but actually we are not afraid of this. When
we enter a newline, we don't complete anyway since the
refresh pattern is not matched, and when we backspace to a
previous line, and the line happens to end with something
that will trigger a completion, why do we not want to
trigger it?
* Also compare completion base to determine context change
It is possible that in some situation changing the text under the
cursor does not change the position of the cursor, so we also
compare the completion base to determine whether the context has
changed.
Yasuhiro Matsumoto
David Briscoe
ii41
Prabir Shrestha
Andrey Popp