[vim/vim] completion list is miss sorted after complete() (PR #21103)
glepnir
Problem: With 'completeopt' "fuzzy", a resort after complete() leaves the
last match unsorted at the end of the list.
Solution: Find the original text by its flag instead of assuming
compl_shows_dir points at it.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/21103
Commit Summary
- 493bc99 completion list is miss sorted after complete()
File Changes
(2 files)
- M src/insexpand.c (16)
- M src/testdir/test_ins_complete.vim (12)
Patch Links:
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#21103)Thanks, I see the test currently fails, so changing the if condition is probably right.
However, I am slightly worried about the new else case. It doesn't cut off the leader anymore (as the function comment claims) and there does not seem to be a test for this. And finally I'd say the test should not leave out the first byte of the line but compare the whole line directly.
So I don't think this is ready yet.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
glepnir
glepnir left a comment (vim/vim#21103)Resolved.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
h_east
h-east left a comment (vim/vim#21103)The force-push took care of the test comparing the whole line. The else case
is untouched, though, so that one still looks open to me.
It unlinks compl_first_match->cp_prev and puts it back at the tail, which is
right only while that node is the original text. Nothing checks that it is.
ins_compl_set_original_text() has the same node to find and looks at both
ends for it, doing nothing when neither matches (insexpand.c:2829). Doing that
here as well, or pulling the search into a helper both of them use, would put
the assumption in the code rather than leave it implied.
compl_T *compl = NULL; -- the initialization is never read, compl is
assigned two lines further down.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#21103)thanks
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.