Include exact matches in auto-complete list

[johnburnett]

Problem description

In spite of ST4 doing an awesome job including more in the auto-complete list, in some ways auto-complete has become subtly more frustrating for me. It's not major though, so I've largely been ignoring it and moving on.

However, I recently realized I hit one example fairly frequently: if you’ve typed something that is an exact match to an auto-complete suggestion, the suggestion sometimes switches to a less-exact match. This particularly hits languages like Python where the lack of statement terminators like ";" make it likely you'll hit "enter" to get a newline while the auto-complete is up, inadvertently auto-completing to what you don't want. As an example, in a fresh instance of Sublime, create a Python file with this:

some_truthy_value = 42
foo = True
assert foo ==

...and then, after the equality check at the end, type "True". For the first three characters, the auto-complete suggestion list will be:

True
some_truthy_value

...but as soon as you finish typing the full word, the suggestion list reduces to just "some_truthy_value", and hitting enter (as would come naturally in an assert statement like this) will then get you the wrong thing.

It feels like if there is an exact match for what you just typed, that should stay on the top of the suggestion list.

After posting this to the support forum, a reply pointed to #3434, and this comment specifically shows the new behavior is intentional ("if what the user types exactly matches a simple completion, it will be hidden since it provides no value", which I think might be the crux of the disagreement).

I debating between filing this as a bug vs a feature request, and landed on "bug" due to it being a regression in behavior vs ST3 from my POV.

Preferred solution

The exact match wouldn't be removed.

Alternatives

Add an option ("auto_complete_include_exact_match" defaulting to false?) to settings to make this configurable.

[cdeegz]

I hope my comment is relevant and not me misunderstanding this issue report...

I agree that this is a bug, and has made coding in ST4 unbearable for me. e.g. I might be looking at another window whilst typing, only to end up with garbage code. For example I type an if/else statement like:

if(condition)
{
  do thing
}
else

as soon as I hit enter after typing 'else', I don't get 'else', in my particular instance, I end up with a member variable ST4 has collected from another file in my project with similar letters that was suggested by autocomplete.

if(condition){
  do thing
}
_elapsed{
  do other thing
}

When I go back to looking at my code window, it doesn't say what I typed, it has broken code. This is simple breakage of the code editor. If the devs insist on breaking the editor, then I vote for the solution suggested above to unbreak it.

[AndrzejKowalski9917]

I also think this "feature" is annoying and filed Issue #4422. Sadly with no reaction so far. Luckily, this made me check out Visual Sudio Code, which I like very much so far. There are very good extensions for VHDL (which I code most) and Python (and C/C++ and ... a lot more). Maybe give it a try. I think I'll stick with it.

As a workaround in ST4, I found, that if you type your word completely, you can insert a new line without triggering auto-completion by hitting "ctrl + enter" instead of just "enter".

[ryanolsonx]

Any progress on this? Is this being considered by the dev team? This is an incredibly irksome bug where the workaround is changing my muscle memory. :(

[TRPB]

Yes, this is particularly annoying. I posted this on the forum but as an example when using PHP I have to type <?php at the top of each file. If I type <?php and press enter, sublime converts it to <?phpcredits() and I have to manually fix it, every damn time.

[weroh]

This is one of those classic cases where a behavior is "correct" by engineering standards, but is so widely problematic that it's totally asinine to ignore and not create a hard-coded workaround for. Code written for machines, not people.

[ryanolsonx]

I think my biggest grievance with this one is how it worked in sublime text 3 vs sublime text 4. Sublime text 3 didn't have this issues, but 4 does. :(

[weroh]

I'm also looking for workarounds if anyone has suggestions. Maybe we could just delete the two suggestions that start with php...

phpcredits phpinfo

I haven't figured out how to do this since I only have read-only access.

[jfcherng]

I'm also looking for workarounds if anyone has suggestions. Maybe we could just delete the two suggestions that start with php...

phpcredits phpinfo

I haven't figured out how to do this since I only have read-only access.

That particular case (the php starting tag) has been resolved for months on https://github.com/sublimehq/Packages/pull/3237. But if you don't know how to use it and you are a unregistered user, it takes months for the next stable build to land on.

[TRPB]

That's only a workaround though. There are dozens of annoyances like this. For example, in PHP type iterable and press enter, it turns it into import_request_variables(types) void gets turned into vpopmail_del_domain(domain), array gets turned into $arrayName = array('' => , );

So if you're typing out a method with a return type:

private function foo(): iterable
{
}

When you add the new line, the return type is overwritten with an expression that makes no sense in the context.

[deathaxe]

The overall point is: If a keyword (e.g.: iteratable) 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 a keyword (e.g.: iteratable) 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 "auto_complete_commit_on_tab": true, so completions are committed using tab rather than enter.

See also: https://forum.sublimetext.com/t/auto-complete-for-exact-matches-doesnt-work/64067/2?u=deathaxe

EDIT: replaced "tab_completion" by "auto_complete_commit_on_tab".

[weroh]

Ah switching to tab vs enter is a sufficient workaround for me. I had to use this instead:

"auto_complete_commit_on_tab": false,

I'll try this for a while and will likely upgrade to V4 now. Thanks!

[rchl]

So I guess this could be summarized as:

If the completion is of a snippet type (COMPLETION_FORMAT_SNIPPET and likely also COMPLETION_FORMAT_COMMAND) then the completion should not be hidden from the popup when trigger matches typed text exactly because it's not guaranteed that the trigger is the same as the text that would be inserted by the completion.

[ryanolsonx]

I still think this is a bug for many use cases