Developer command palette entries should always be at the bottom

[Tyriar]

I've built muscle memory for switching themes via the command palette which I'm having difficulty getting rid of. Regardless, I don't think the first result for "theme" should be generating theme json.

[bpasero]

I see the issue but our command picker has a strict sorting by alphabet and nothing else. I tried to just sort by shortest match, but that caused other frustration (see #25682)

Duplicates: #14727, #20553, #1964

[Tyriar]

@bpasero could it not be strict alphabetical sorting with the exception of "Developer" prefixed commands which are always at the bottom of the list? That way the dev/debugging stuff doesn't get in the way for regular users.

[bpasero]

@Tyriar possible, but how do you know it is of that category? For us it is currently just a label, so we need to introduce the concept of "developer" commands.

[Tyriar]

@bpasero I guess it would need that yeah.

[bpasero]

PR welcome.

[Tyriar]

@bpasero where abouts is the code for the command palette sorting?

[ihalip]

I think the sorting is being done in src/vs/base/parts/quickopen/browser/quickOpenModel.ts, see QuickOpenEntry.compare().

[bpasero]

@Tyriar right here: https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/parts/quickopen/browser/commandsHandler.ts#L289

[kdmu]

Hi @Tyriar are you working on this issue? If not I would like to pick it.

[Tyriar]

@kdmu I was going to but it would be great if you could help out 😃

[kdmu]

@Tyriar Let's give it a try 😃

Which kind of filtering are we expecting to have after this issue? Is enough if we just filter out developer commands based on entry label prefix? Or we want to introduce the notion of command type, let's say developer and nonDeveloper?

[Tyriar]

@kdmu I'm expecting exactly the same behavior as now, just "Developer" prefixes entries are in a sorted list below the main sorted list. You would likely need to introduce a new "isDeveloperCommand` flag to commands so that we don't need to do a string search on start up.

[kdmu]

@Tyriar not very clear about what do you mean by string search on start up. Adding isDeveloperCommand to BaseCommandEntry will require us to do a string matching with label. The only way I can imagine that we can avoid this is add the flag when we instantiate the command itself like here, however it seems it may lead to inconsistency.

My initial approach was filter out developer commands using a regex and sort both entries separately, the behavior will be the same but it will require us do string matching whenever commandHandler is invoked.

[Tyriar]

@bpasero please advise the ideal solution 😃

[bpasero]

I think having a flag when creating these commands that identifies normal commands from developer commands is the only way that works across all languages, where "Developer" might be translated to something else.

[kdmu]

@bpasero not familiar with vscode code base, I'll need some guidance about command's hierarchy.

I see those "Developer" commands are different type of commands? Taking as example: "Developer: Inspect Key Mappings" is instantiate as Command, while most of developer commands are like "Developer: Generate Color Theme From Current Settings" instantiated as ICommand though workbenchActionsRegistry

I'm guessing there's "parent" that all "Developer" share in common, is that true? If not I guess we will need to modify both type of commands.

Developer actions

[bpasero]

I suggest to look at the registerWorkbenchAction method and add an overload that allows to declare a command as being a developer command (or any kind of category). E.g. instead of having category?: string we could have an overload that accepts { label: string, kind: enum }

[kdmu]

While most of "Developer" commands are WorkbenchAction and registered through registerWorkbenchAction, I found some of them do not, there's EditorAction like "Developer: Inspect <Key Mappings|TM Scopes>" registered through other mechanism or "Developer: Webview Tools" being registered through CommandsRegistry and MenuRegistry.

@bpasero are my thoughts on the right track? If they are I guess we may need to take care of those non-WorkbenchAction apart from overloading registerWorkbenchAction (?)

[bpasero]

Yeah tricky. Sorry I am not having enough time to look into this further at the moment.

[kdmu]

If we can afford the cost of string matching, a possible solution could be filtering entries based on label and alias. If I am not wrong, although label is translated in the destination language, alias is kept in english.

[bpasero]

No plans to change this.