Remembered suggestion selections can be annoying

[SDanton]

• VSCode Version: Version 1.19.1 (1.19.1)
• OS Version: 10.12.6 (16G1036)

Steps to Reproduce:

1. Type as per normal e.g. 'actor', see code completion list
2. Notice that fully matching value 'actor' is not matched, but the next closest value is 'ActorMgr'
3. (Side effect) Press Escape to avoid matching undesired value

https://imgur.com/lpt0DKg

Expect:

If I type in an exact match, then that should be the value I will get after tabbing / entering, not the next closest match.

[jrieken]

The reason for that is that VS Code remembers selected suggestions per prefix and language. When typing actor and selecting ActorMgr it will preselect that on subsequent invocations. Select the actor-suggestion and it's back to 'normal'.

Not yet sure how to handle these situations as there are cases. In some scenarios the same prefix is used for different suggestions in an alternating fashion... Open for suggestions

[SDanton]

The current approach feels like it's trying to be too smart. If we have a case sensitive exact match I feel like that should always override a predictive match. Do we have scenarios where this isn't the case?

Alternatively, if I had entered 'ac' and then pressed tab, then yes I can see ActorMgr matching. Then again, case sensitivity is something I'm very aware of when I code, so I feel it should still put 'actor' first.

Possible rules:

1, Exact match always wins
2, Case matters, if 'ac' is entered, 'ac*' always matches before 'Ac*'

A few other thots:

// Can I turn off "suggestion matching" and enable case-sensitive-exact-match-wins intellisense? Isn't this how intellisense used to work?

// It's unclear to me this kind of matching will ever work in code bases with variables / class names that share common sub-strings. Which I would guess is most code bases.

Consider a code base which has actor, ActorMgr and ActorCtrl. If I use all of these frequently intellisense is going to guess incorrectly 66% of the time. Just because I used 'actor' last time does not mean I will use it this time. The more I think about it the more I'm convinced this just won't work -- it's just too easy to guess incorrectly. I can see cases for "auto-correction" e.g. if I type 'actro' and I've used 'actor' several times in this context before, perhaps it should auto-correct to 'actor'?

(Below are more ideas... they might help in some cases, but I think the feature has fundamental challenges.)

// Perhaps we only suggest after we have context. Consider...

I enter "actor", no suggesting, just case-sensitive intellisense
With actor as my context, we now suggest, so if I enter actor.Anim we suggest Animator

... again this presents challenges. If actor has an Animator and an AnimatorManager, it will guess incorrectly half the time.

// Visual highlighting of the "current match" should be stronger, I don't think this will help much but it will at least make things more obvious.

// Can we better leverage context? It feels like we currently remember selections by project...? Could matches be relative to the code file, class or even function? Not sure this really helps, might make things more confusing actually :).

// What means do we have to "override" a match. Consider...

1, Entering 'actor' pressing tab
2, Getting 'ActorMgr' match
3, Backspacing over 'ActorMgr'
4, Entering 'actor' pressing Escape

... backspacing and then escaping out of the suggestions definitely has intent from where I am sitting, can the system reliable leverage that? Perhaps escaping when there is an exact match matters?

[SDanton]

Just wanted to add to this... I'm now more confused as to how the suggestion system works.

Consider below...

https://imgur.com/Fb5Yidl

... having entered '_canRo' how is it that '_canGuardCounter' or '_canChargeCounter' match? Further, how is that _canGuardCounter is the selected match?

I see that the letters 'r' and 'o' are in *GuardCounter and *ChargeCounter but I would have to be a really bad typist to have entered _canRo and expect either of the suggested options.

(By the way, I know how hard everyone works on these features... I don't in any way want to come across as not appreciating all that hard work -- I've been in your shoes :). At the same time I want to help improve VS Code b/c it's the tool I use everyday. If I'm negative or direct, it's only b/c I've found that's the fastest way to make something better. It's never personal.)

[jrieken]

Further, how is that _canGuardCounter is the selected match?

Consider two sides of this: Sorting and Selection. The sorting is based on a rank that is computed with the current prefix and each suggestion. From looking at your screen shots the sorting is correct (better matches comes first). Now selection: By default the first item in the list is selected, it's the best match. However, if a user selects a different suggestion (not the best match) for a prefix we remember that and we will select that item the next time this case comes up.

So that's what's happening here, your problem isn't sorting but pre-selection. You can easily "fix" this by just accepting a different suggestion and we believe depending on the current task that happens. For instance I usually complete cons to const but when I'm ghetto-debugging I complete cons to console. It becomes a problem when using then interleaving which I believe is rare.

... having entered '_canRo' how is it that '_canGuardCounter' or '_canChargeCounter'

see https://hackernoon.com/heres-to-fat-fingers-f39a5c778c4c

So, given the new insights how can the remembering be improved? Suggestions, Ideas?

[SDanton]

Thanks for the context. Helpful.

A few ideas:

1. Case should matter. cons should match const before Constant

2. Exact match should "win". Entering const and pressing tab/enter should match (and be highlighted / selected) even if there is a constant in the selection list.

3. Consider breaking filter down into primary and secondary matches. If I enter _canRo then anything with that specific string is my primary match. Matches containing any of the values in _canRo are secondary matches. Further, secondary matches have a min-sub-string length that must be met before matching, perhaps 2 consecutive values? That would mean _canGuardCounter or _canChargeCounter will match while I've entered _can, but drop off as soon as I enter _canR as that specific sub-string cannot be found in either of them.

3b. Reading the hackernoon article... it seems we want to auto-correct for cases in which a dev swaps two letters "accidently" -- not sure what you call this, feels like a form of Spoonerism. But we don't want, although seem to currently have, "deep-matching" of just any singleton values across a string. For instance, we want funciton to get replaced with the function, but just because I have it in my candidate string doesn't mean I match everything with fun and an i or t. This would seem to suggest that we do indeed want a min-length on sub-string matches. Given that rule, we wouldn't see _canGuardCounter or _canChargeCounter as suggestions, right?

4. Escape should act as a selection candidate. If I enter const and press escape then continue working then we should update the selection system to reco const as if I'd pressed tab/enter.

5. Escape + backspacing / deleting selection should count against a selection. If I enter const press escape then backspace / delete const or update const to be something like constWidth then my updated string constWidth should be considered my selection as if I'd selected it from the suggestion list.

[chronicgamedev]

Hello - Interesting discussion. I'm running into this issue in my current project as well where the autocomplete suggestions appeared to insert the wrong item. I realized that the suggestions were "remembering" the previous selection and that's what led me here. I'd argue that similar variable names and "interleaving" them while coding is not rare at all. By making the selection feature smart, it feels like the UX takes control away from the user instead.

For example, I have Client and Server implementations of several objects and as I work back and forth intellisense (subjectively) feels like it's always picking the wrong one. It's definitely slowing me down with extra keystrokes, deletions and interrupted focus.

I would love it if I there were a setting to disable the remembered selection and always default to the best match at the top of the autocomplete list. That would let folks pick the behavior that matches their work style.

[jrieken]

@chronicgamedev Thanks for the feedback... Adding a setting is always in reach but also less ideal because folks need to discover and we all need to argue about the default ;-) The client, server sample is good input. Today we remember things per language but maybe we should store it per file. So instead such a key storage://workspace/Users/jrieken/Code/vscode/suggest/memories/typescript we could have storage://workspace/Users/jrieken/Code/vscode/suggest/memories/my/server/file.ts and remember selections for that

[SDanton]

Never fun to realise the dev team isn't actually reading your comments... I suggested scoping things in my second comment...

// Can we better leverage context? It feels like we currently remember selections by project...? Could matches be relative to the code file, class or even function?

Good to see you read @chronicgamedev's note, but now I feel like I'm just wasting my time here :|.

[tempit]

Hi there. Interesting discussion indeed, from both user and extension writer perspectives.
To throw my two bits in, I think the 'remember last selection' feature is overkill, and I agree with @chronicgamedev that the situation where two or more completions apply and I use them interchangeably is more common than you'd think. I'm for cancelling this feature, as it seems to cause more confusion than help.
As for case-sensitivity, I am very strongly for keeping it the way it is. it is most useful when investigating poorly documented APIs (TS compiler TypeChecker, in my case). When trying to see all methods that return a type of some sort, it is very useful to type 'gettype' or even 'gtype' and get both 'getType' and 'getUntypedSymbol' (I made up the function names, but the example is clear, I hope).

[NakOh]

Yeah.. I am embarrassed with smart suggestions.

Maybe this suggestion don't need.

Even if I choose another proposal at least once, there is not enough ground to judge whether the choice will continue to be valid or not.

I want to turn off the ability to remember my choice, but I do not know how.