favor local types and values in autocomplete popup over ambients declaration
zpdDG4gta8XKpMCd opened this issue ยท 15 comments
it's not clear to me what drives the order of the list of autocomplete popup suggestions, i wish my local types and values were listed first, and ambients came after them
This was reported against VSCode recently as well: microsoft/vscode#29613
For code such as:
var cancel = 123
can|
The suggestions for can
have the same sort text:
{
"name": "cancel",
"kind": "var",
"kindModifiers": "",
"sortText": "0"
},
{
"name": "cancelAnimationFrame",
"kind": "function",
"kindModifiers": "declare",
"sortText": "0"
}
I believe that variables and parameters should have a higher sort text (or that globals should have a lower sort text)
A feature that VS has today is remembering the last entry the user selected in the completion list. so the first time you type cancel
it does not get it, but next time it gets a preferential treatment. I think this is a general feature that would be beneficial to VSCode users in general given the locality of reference for variables in general, and less disorienting as reordering based on scope.
I'd still prefer local scope to get higher weighting. The remembering of the last selection only solves a small subset of the use cases that I care about.
VS Code has added support for remembering suggestions with the editor.suggestSelection
setting.
I still think that adding some basic sorting based on scope would be very helpful. @DanielRosenwasser Can we revisit this feature request?
@sheetalkamat this is something we'd like to deliver for 3.5 specifically
More VS Code feedback related to suggestion sort order and locality: microsoft/vscode#47727
there is also a very annoying thing with remembering-last-entry bonus:
- say i needed
[].filter
but by accident i picked[].fill
now thefill
gets preference overfilter
and gets on the way even more often, so i pick it by accident even more, and it all goes in a vicious circle
how do i unfavor some accidental picks?
how do i unfavor some accidental picks?
If you Undo (Ctrl+Z
) after accidentally selecting fill
, I'd expect it to not leave fill
in that "last list".
The ordering we think might be best:
- Things from the lexical scope that are declared in the current file (including top-level variables in a script file)
- Suggested class members
- Things from global lexical scope and keywords
- Auto-import suggestions
Caveat: "real" things (non-suggestions) should always shadow suggestions
@RyanCavanaugh @mjbvz
In example from #30013 making Things from the lexical scope that are declared in the current file (including top-level variables in a script file)
as first makes suggested class members
render
Also what happens to javascript symbols. Current behavior is that everything except JavaScript has "0" and JavaScript symbols are "1". Does JavaScript come after auto import ?
Yeah that doesn't feel right. We should either:
- Merge the class member and lexical scope precedences.
- Introduce two levels of lexical scoping:
- Locals (things from inside the current method)
- class members
- File Lexical scope
- global lexical scope and keywords
- Auto-import suggestions
The first approach definitely seems more straightforward. VS Code's suggestion sorting should also help out so that better matches are shown first
For the second point, the javascript symbol suggestions (we call them name suggestions
in vscode) should probably have the lowest precedence. They are sort of the equivalent of VS Code's word based suggestions, which also have very low precedence and are only really meant to show up when no other suggestions match
how about we give it as a configurable option?
something like:
{
"auto-completion-priorities": ["locals", "members", "lexical", "ambients", "imports"]
}
or
{
"auto-completion-priorities": "merged"
}
it would be nice to have some visible separation between the groups (shades of background)
better yet first N.. something items of each group with an option to dig deeper:
aaaa
aaab
aaac
aaad
... more locals
bbba
bbbb
bbbc
bbbd
... more globals
and please make N configurable (per each group)
... looks like an overkill, disregard please