Add support for identifying third party commands

[richtabor]

As plugins start adding commands using the the Command Palette API, it would be nice if each command registered had the associated plugin name visible in the command. This way if there were competing commands (either between third-parties, or between a third-party and core) you would be able to identify which command you were looking for.

Not every command would utilize the plugin's branded icon (perhaps there isn't one even)—so we can't rely on just the visual.

It could be interesting if the plugin name was used as a fallback, but the command could register an alternate. There are considerations on both fronts, but I'm concerned about plugins that use extensive names (i.e. "Ninja Forms Contact Form – The Drag and Drop Form Builder for WordPress" — where the visible name should be "Ninja Forms".

Related to #53190 in theory. Perhaps the identification here—and type/category within that concept—are the same idea.

Visual

[jasmussen]

Good and valid issue. The visual looks good too, but I'm wondering, what can we do to reduce the visual footprint so as to make each item more legible? The more complex the silhouette, the longer it will take to parse, in my experience.

In this case, including both icons and the textual representation seems a lot, and text-wise there's a concern of very long plugin names. Icon-wise, what if a plugin does not offer an icon?

Would be possible to add a smaller icon only for plugin additions, like we have a "lock-small" icon? Or perhaps when both core and plugin commands are found, they are grouped separately with core commands on the top, and then a group for plugin commands below? (I know we just removed a grouping border, but perhaps it can be a different type of separator or just whitespace.) An additional option might be to show a plugin name only on highlight/focus, and then make sure it's elided if the name is longer than n characters (and denoting max-chars in the API).

[richtabor]

Icon-wise, what if a plugin does not offer an icon?

My thought is that icons are entirely command-based.

Third-party plugins can either add their own brand icon (like in the Jetpack "Activity log" command above), a relative icon (like in the Yoast "Social previews" command, or no icon at all per #53193.

The plugin/category/source detail on the right would be consistent though.

Would be possible to add a smaller icon only for plugin additions, like we have a "lock-small" icon? Or perhaps when both core and plugin commands are found, they are grouped separately with core commands on the top, and then a group for plugin commands below?

I don't think we should separate core and plugin commands. Perhaps if there's a 1:1 match, core's should be prioritized, but generally I think they could be intermixed just fine.

An additional option might be to show a plugin name only on highlight/focus, and then make sure it's elided if the name is longer than n characters (and denoting max-chars in the API).

The bit there is that I wouldn't want to require navigating to a command to understand what it is. Imagine "General settings" commands, but one for core, one for Jetpack, another for Yoast, etc — but the palette reads "General settings", "General settings", "General settings".

Yes, we should truncate the category/type/source text if we roll it out.

[richtabor]

An alternative, but we already decided against this pattern.

Plus, I think it's more difficult to parse and doesn't help provide additional context that could be employed as #53190 (comment) (if "Post" was set as the category/type/source on the right).

[jasmussen]

The bit there is that I wouldn't want to require navigating to a command to understand what it is. Imagine "General settings" commands, but one for core, one for Jetpack, another for Yoast, etc — but the palette reads "General settings", "General settings", "General settings".

Right, definitely don't want mystery meat navigation, but the idea here would work only if the note on the right was the plugin short-name, and not a category of action.