Skip to content

Conversation

lbiaggi
Copy link

@lbiaggi lbiaggi commented Aug 4, 2025

This commit introduces a new custom_regex option under the fuzzy configuration.

It allows users to specify a custom regular expression to be used by both implementations.

This commit introduces a new custom_regex option under the fuzzy
configuration. It allows users to specify a custom regular expression
to be used by both implementations.
@Saghen
Copy link
Owner

Saghen commented Sep 2, 2025

Thanks for the PR! Sorry for the wait, I've been away on vacation.Right now, this PR edits the regex used for getting words for the buffer source and proximity bonus. I'm not sure if that was your intention, or if you wanted to change the regex used for getting the keyword.

If it's the former, we should put this option at sources.providers.buffer.opts.regex = function(type) if type == 'lua' then return ... else return ... end. The get_words function should accept the regex, and update it, if it's different from the existing cached one. We need separate lua and rust regexes because they use different syntax, and making it a function lets people customize per language.

If it's the latter, we should put an option at completion.keyword.regex = function(type) if type == 'lua' then return ... else return ... end. On every invocation of fuzzy, get_keyword_range and guess_edit_range, we should accept the regex. If the regex is different from the current in keyword.rs, we should parse and cache it. This one's a bit tricky as there's separate forward and backwards regexes.

@lbiaggi
Copy link
Author

lbiaggi commented Sep 2, 2025

@Saghen Hi, when I did, it was for the latter, for my use it works quite fine. Honestly, I don't mind transforming this into your first suggestion, my only concern is that creates an option specifically for an implementation.

@lbiaggi
Copy link
Author

lbiaggi commented Sep 2, 2025

Just to confirm for lua you meant vim regexes, right?

@Saghen
Copy link
Owner

Saghen commented Sep 2, 2025

Yeah, I meant vim regexes

Hi, when I did, it was for the latter, for my use it works quite fine. Honestly, I don't mind transforming this into your first suggestion, my only concern is that creates an option specifically for an implementation.

Afaict, this is unavoidable unless we figure out a way to convert rust regexes to vim regexes reliably. For example, in Rust, we use \p{L} for alphabet characters, which supports many languages, but there's no equivalent in vim afaik.

@lbiaggi
Copy link
Author

lbiaggi commented Sep 2, 2025

Yeah, I meant vim regexes

Hi, when I did, it was for the latter, for my use it works quite fine. Honestly, I don't mind transforming this into your first suggestion, my only concern is that creates an option specifically for an implementation.

Afaict, this is unavoidable unless we figure out a way to convert rust regexes to vim regexes reliably. For example, in Rust, we use \p{L} for alphabet characters, which supports many languages, but there's no equivalent in vim afaik.

I will do a few tests, but I think vim's \p (match printable characters, but this relies on isprint is similar but not the same as Rust's \p{L} which IIRC is a PCRE thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants