Smarter fuzzy completion matches

[rolandwalker]

Description

• Rename parameter orig_text and don't overwrite text.
• Limit regex fuzzy match to 3-character intervening spans for performance and readability of results.
• Add underscore-split match. If the underscore-split words in the text are a subset-match of the underscore-split words in the completion item, we have a candidate match. Subset-match is defined as "every word in the user's input is at least a leading substring match to at least one separated candidate word". [Edited]
• Add CamelCase-split match. If the CamelCase-split words in the text are a subset-match of the CamelCase-split words in the completion item, we have a match. Subset-match is defined as "every separated word in the user's input is at least a leading substring match to least on separated candidate word". [Edited]
• Remove unused length and position values from tuples, letting "completions" be just a list of strings.

The words within the underscore and camel-split matches are not themselves fuzzy, and must be exact matches. It might be neat if we accepted leading substrings from all of the words instead. Done: exact matches, but leading substrings are sufficient for a match.

Beyond that, if we need anything more fancy we should use a library rather than rolling our own.

This may close some open issues.

Will cause a merge conflict with #1448, to be resolved later.

Like #1448, the inspiration is to improve completions after adding more possible matches in #1447.

Example showing underscore-split match:

Checklist

• I've added this contribution to the changelog.md.
• I've added my name to the AUTHORS file (or it's already there).
• I ran uv run ruff check && uv run ruff format && uv run mypy --install-types . to lint and format the code.

[scottnemes]

RE: the split match functionality, I am comparing it to main and it seems to work the same as far as I can tell. Is there another case that highlights the expected difference?

[rolandwalker]

@scottnemes OK, the above is a better example. What main does currently is check every letter, in order, with any number of intervening characters. Since z.*?o.*?n.*?e matches zone, you get a completion candidate. This is inefficient and leads to VERY many spurious matches.

The underscore part of the proposal here is to split terms on underscores, and match if every complete underscore-separated subword in the typed text is present in the candidate, independent of order. (But not every subword in the candidate needs to be covered, just some subset.)

A further proposal for a followup PR would be to accept leading substrings, rather than requiring complete subwords, so that sec_zon would match the candidate time_zone_leap_seconds.

A further proposal for a followup PR would be to adopt some other library for fuzzy matching, as many smart people have already thought about this problem.

[rolandwalker]

@scottnemes at the same time you were approving, I had some changes outstanding which added the leading-substring-match for underscore- and caps-separated words. Pushed those changes now.

[scottnemes]

@scottnemes at the same time you were approving, I had some changes outstanding which added the leading-substring-match for underscore- and caps-separated words. Pushed those changes now.

Nice! Underscore works as expected

For CamelCase, I don't see the same behavior though

[rolandwalker]

For CamelCase, I don't see the same behavior though

Ah, the limitation is that the candidates must also be CamelCased.