Sublime Forum

Auto-complete for exact matches doesn't work

#1

Just checking in if there’s a known workaround for auto-complete of exact matches not working properly in ST4 (where it did work in ST3).

This is logged under https://github.com/sublimehq/sublime_text/issues/4810 , but it’s hard to tell where to get a response/confirmation/rejection.

0 Likes

#2

The inital post of linked issue 4810 points to https://github.com/sublimehq/sublime_text/issues/3434 which contains the history and motivation of that change.

To prevent simple (word) completions from taking precedence over snippets or explicit completions, it was decided to remove exactly matching simple completions from the list of suggestions.

The overall intent is to priorize a snippet (or snippet like completion) over simple completions and fix the annoyance of word completions augmenting explicit completions or snippets.


The whole issue was mainly discussed based on the following completions file:

{
  "scope": "source.python",
  "completions":
  [
    { "trigger": "begin", "contents": "begin", "kind": "type" },
    { "trigger": "begin", "contents": "begin\n\t$0\nend;", "kind": "keyword", "annotation": "begin..end" },
  ]
}

Same applies to mix of explicit (simple) completions and snippets:

{
  "scope": "source.python",
  "completions":
  [
    { "trigger": "begin", "contents": "begin", "kind": "type" },
  ]
}
<snippet>
	<content><![CDATA[
begin
	${0}
end;
]]></content>
	<!-- Optional: Set a tabTrigger to define how to trigger the snippet -->
	<tabTrigger>begin</tabTrigger>
	<!-- Optional: Set a scope to limit where the snippet will trigger -->
	<scope>source.python</scope>
</snippet>

The latter case may work even without removing simple completions as snippets whose trigger matches exactly the typed word are moved to the top of completions in current releases. This fix was applied after build 4089.


The behavior of removing exactly matching completion candidates is implemented in ST’s core engine and can’t be worked around by user.

The overall point is: If a keyword (e.g.: begin) was fully typed, there’s no need for any completion to be displayed or commited, because hitting space to continue writing is just enough.

The bug is: If the keyword is the last one on a line, hitting enter commits the next best completion/snippet instead of inserting a newline. This can be worked around by setting "tab_completions": true, so completions are committed using tab rather than enter.

3 Likes

#3

deathaxe: thanks for the response. I understand why the behavior is the way that it is, and what the history is. I’m hoping one of the devs (@wbond?) might reconsider the change in ST4 (specifically when wbond said “we now will hide simple completions that match the text the user has entered.” it implies the use case above wasn’t considered when they removed the feature).

0 Likes