[RFC] keywords likely to appear at the end of a line should `cancelCompletion`

[deathaxe]

Relational

Discussions about variables or keywords being expanded to something invalid by hitting enter key at the end of a line.

The reason is ST removing the perfect matching completion from the auto completion popup (see also https://github.com/sublimehq/sublime_text/issues/3434), which causes the 2nd best match to be committed instead of adding a newline.

Example

If the word thena has been typed somewhere in the file and enter is hit directly after fully typed keyword then at the end of a line, it is expanded to thena, while adding a newline is expected.

Proposal

it's an issue with the default packages that ship with Sublime Text: all keywords that commonly appear in a trailing position on a line should be mentioned in a cancelCompletion preference, ideally

source: https://discord.com/channels/280102180189634562/280157083356233728/1069813308074491984

The following pattern causes completions to be canceled, if a line is finalized by the given list of keywords.

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
	<key>scope</key>
	<string>source.lua</string>
	<key>settings</key>
	<dict>
		<key>cancelCompletion</key>
		<string>^.*\b(?:break|do|end|else|repeat|return|then)$</string>
	</dict>
</dict>
</plist>

with ^.*(?:<list of keywords>)$ matching only if the keywords really finalize the line, basically every known keyword could be added here without preventing further completions. As soon as any character other than newline is added after given keyword, the pattern doesn't match and completions are re-enabled again.

Limitations

Extending existing statements

It doesn't however prevent known keywords from being expanded, if an existing statement is to be splitted into multiple lines.

before enter

if foo then| print("bar") end

after hitting enter

if foo thena
    | print("bar") end

Arbritary identifiers

It doesn't work if the final word in the line is an arbritary identifier, such as a well-known variable.

var foo;
var foobar;

foo|

expands to

foobar
|

[keith-hall]

I personally wonder whether cancelCompletion should get deprecated in favor of a new tmPreferences key which would work on the scope of the token to the left of the caret... If it is keyword.control.conditional.then, for example, it likely should cancel completions. So, selector based instead of regex based.

This could solve the problems with cancelCompletion when splitting lines, poor performance due to using Oniguruma regex engine, having to duplicate what it can already tell from the tokenization, and the completions being cancelled no matter where the caret is on the line just because the line happens to match the regex pattern.