feat: allow functions in 'complete' to complete from non-keyword #17651
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
|
As a side note, can we have an API (a function?) that can trigger completion instead of relying on |
Contributor
Author
It's possible. I'll think about it a bit. It has to be a separate PR though. |
…cters Previously, functions specified in the `'complete'` option were restricted to starting completion only from keyword characters (as introduced in PR 17065). This change removes that restriction. With this change, user-defined functions (e.g., `omnifunc`, `userfunc`) used in `'complete'` can now initiate completion even when triggered from non-keyword characters. This makes it easier to reuse existing functions alongside other sources without having to consider whether the cursor is on a keyword or non-keyword character, or worry about where the replacement should begin (i.e., the `findstart=1` return value). The logic for both the “collection” and “filtering” phases now fully respects each source’s specified start column. This also extends to fuzzy matching, making completions more predictable. Internally, this builds on previously merged infrastructure that tracks per-source metadata. This PR focuses on applying that metadata to compute the leader string and insertion text appropriately for each match. Also, a memory corruption has been fixed in prepare_cpt_compl_funcs().
Member
|
So if I understand this correctly, |
Contributor
Author
Yes, you're absolutely right — |
Member
|
thanks |
Contributor
Author
|
Thanks. |
zeertzjq
added a commit
to zeertzjq/neovim
that referenced
this pull request
Jul 5, 2025
…ters
Problem: completion: can only complete from keyword characters
Solution: remove this restriction, allow completion functions when
called from i_CTRL-N/i_CTRL-P to be triggered from non-keyword
characters (Girish Palya)
Previously, functions specified in the `'complete'` option were
restricted to starting completion only from keyword characters (as
introduced in PR 17065). This change removes that restriction.
With this change, user-defined functions (e.g., `omnifunc`, `userfunc`)
used in `'complete'` can now initiate completion even when triggered
from non-keyword characters. This makes it easier to reuse existing
functions alongside other sources without having to consider whether the
cursor is on a keyword or non-keyword character, or worry about where
the replacement should begin (i.e., the `findstart=1` return value).
The logic for both the “collection” and “filtering” phases now fully
respects each source’s specified start column. This also extends to
fuzzy matching, making completions more predictable.
Internally, this builds on previously merged infrastructure that tracks
per-source metadata. This PR focuses on applying that metadata to
compute the leader string and insertion text appropriately for each
match.
Also, a memory corruption has been fixed in prepare_cpt_compl_funcs().
closes: vim/vim#17651
vim/vim@ba11e78
Co-authored-by: Girish Palya <girishji@gmail.com>
zeertzjq
added a commit
to zeertzjq/neovim
that referenced
this pull request
Jul 5, 2025
…ters
Problem: completion: can only complete from keyword characters
Solution: remove this restriction, allow completion functions when
called from i_CTRL-N/i_CTRL-P to be triggered from non-keyword
characters (Girish Palya)
Previously, functions specified in the `'complete'` option were
restricted to starting completion only from keyword characters (as
introduced in PR 17065). This change removes that restriction.
With this change, user-defined functions (e.g., `omnifunc`, `userfunc`)
used in `'complete'` can now initiate completion even when triggered
from non-keyword characters. This makes it easier to reuse existing
functions alongside other sources without having to consider whether the
cursor is on a keyword or non-keyword character, or worry about where
the replacement should begin (i.e., the `findstart=1` return value).
The logic for both the “collection” and “filtering” phases now fully
respects each source’s specified start column. This also extends to
fuzzy matching, making completions more predictable.
Internally, this builds on previously merged infrastructure that tracks
per-source metadata. This PR focuses on applying that metadata to
compute the leader string and insertion text appropriately for each
match.
Also, a memory corruption has been fixed in prepare_cpt_compl_funcs().
closes: vim/vim#17651
vim/vim@ba11e78
Co-authored-by: Girish Palya <girishji@gmail.com>
zeertzjq
added a commit
to neovim/neovim
that referenced
this pull request
Jul 5, 2025
…ters (#34798) Problem: completion: can only complete from keyword characters Solution: remove this restriction, allow completion functions when called from i_CTRL-N/i_CTRL-P to be triggered from non-keyword characters (Girish Palya) Previously, functions specified in the `'complete'` option were restricted to starting completion only from keyword characters (as introduced in PR 17065). This change removes that restriction. With this change, user-defined functions (e.g., `omnifunc`, `userfunc`) used in `'complete'` can now initiate completion even when triggered from non-keyword characters. This makes it easier to reuse existing functions alongside other sources without having to consider whether the cursor is on a keyword or non-keyword character, or worry about where the replacement should begin (i.e., the `findstart=1` return value). The logic for both the “collection” and “filtering” phases now fully respects each source’s specified start column. This also extends to fuzzy matching, making completions more predictable. Internally, this builds on previously merged infrastructure that tracks per-source metadata. This PR focuses on applying that metadata to compute the leader string and insertion text appropriately for each match. Also, a memory corruption has been fixed in prepare_cpt_compl_funcs(). closes: vim/vim#17651 vim/vim@ba11e78 Co-authored-by: Girish Palya <girishji@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Allow functions in 'complete' to complete from non-keyword
Previously, functions specified in the
'complete'option were restricted to starting completion only from keyword characters during<C-N>/<C-P>completion (as introduced in PR #17065). This PR lifts that restriction.With this change, user-defined functions (e.g.,
omnifunc,userfunc) used in'complete'can now initiate completion even when triggered from non-keyword characters. This makes it easier to reuse existing functions alongside other sources without having to consider whether the cursor is on a keyword or non-keyword character, or worry about where the replacement should begin (i.e., thefindstart=1return value).The logic for both the “collection” and “filtering” phases now fully respects each source’s specified start column. This also extends to fuzzy matching, making completions more predictable.
The existing behavior — where
<C-N>shows a menu of all words of at least 2 characters when triggered from a non-keyword — remains unchanged.Internally, this builds on previously merged infrastructure that tracks per-source metadata. This PR focuses on applying that metadata to compute the leader string and insertion text appropriately for each match.