ST4 Autocomplete truncates special characters from function-names and other suggestions when they should be included
Opened this issue · 7 comments
Description of the bug
We use SublimeText 4 to script in a lisp-based language that allows special characters like Slashes and Question-Marks in functions, var names, etc. For example:
is-true? and is-true/false
are both valid terms.
But since updating to ST4, Sublime's native autocomplete seems to have started treating characters like ? and / as word-separators, even when these special characters are specifically removed from the "word_separators" setting in our user preferences.
These Special Characters ARE still recognized by ST4's .tm-preferences indexing/tokenization system, and by the double-click select system, but not autocomplete suggestions. So...
- Pressing Ctrl+Shift+R and starting to type is-tr will filter the list to
is-true?(expected)
- Pressing F12 on a typed instance of the function
(is-true?)will jump to the definition of `is-true?`` (expected) - Double clicking on
is-true?yields selectionis-true?(expected)
- Starting to type
is-true?will yield autocomplete suggestionis-true(BUGGY)
Also, for some reason, other unusual characters that we have removed from the word_separators settings because they're valid terms in our language, like - , (we use kebab-case) are handled fine by autocomplete.
Steps to reproduce
- Set up a Sublime project environment with syntax settings that treat special characters like ?, , * etc as valid parts of words like function-names. (e.g. by specifying them as such in .tm-preferences files and removing them from the word_separators list in Preferences)
- Define a function or other autocomplete-indexed term that includes one of these special characters somewhere within it.
- Start to type the name of the function or term you defined in another file or later in the define file.
- BUG: Note how Sublime Autocomplete's suggestions truncate suggestions from the special character on, rather than including the special characters. (Note also that other syntax-sensitive systems like the Ctrl+Shift+R palette, F12/Goto Definition, and double-click word selection work as expected with the same terms.)
Expected behavior
Special characters that are specified as valid parts of names/terms in our language's syntax and selection preferences should also be included in autocomplete suggestionss.
Actual behavior
Autocomplete treats special characters (including ?, /, *) as word separators or invalid elements for suggestion terms, truncating these suggestions by stripping off the special character and everything following it from the suggestion even when they should be part of it.
Sublime Text build number
4126
Operating system & version
Windows 10
(Linux) Desktop environment and/or window manager
No response
Additional information
No response
OpenGL context information
No response
Also related: sublimehq/Packages#671
I was basically looking for the issue which requests word_separators (and sub_word_separators?) to be respected by each functionality as this seems the root cause of any of those issues.
Yeah @deathaxe , we just did some testing of the new subword separators feature today, and it appears that these characters are not recognized by Sublime as subword separators even when specified in user settings as such:
-?^*=
Update: through trial and error, looks like it's just that characters have to be in BOTH word_separators and subword_separators in order to be recognized as subword_separators
Just discovered something that seems very significant to solving this bug: if I "manually" query the list of Sublime complete suggestions via the extract_completions function, the list it returns is accurate, with the special characters included in the strings. The special characters are also preserved if I feed this list into the completions to be returned via python.
This strongly suggests that something in the formatting phase of the automatic completions list creation is stripping these special characters from the completion strings before presenting them to the user.