Add support for "hidden" commands

[wbinnssmith]

This allows for commands to opt-into not appear in command palette.

Frequently commands are an implementation detail, or even only a means of providing a keybinding, and do not benefit from being shown and selectable to the user from the command palette.

Options like "Vim Mode Plus: Set Input Char M" can be confusing to the user and cloud high-signal commands from surfacing in command palette results.

Additionally, showing so many commands can bog down the command palette and make it slow to start -- though there are certainly other means of improving its performance.

The name (hiddenInCommandPalette) is the most concise I could come up with to convey what we want here. There might be other ways of surfacing commands in an interface that might not want to obey this (or those that might), but for now I'm erring on the side of being specific to command palette. Totally open to making this more generic if there's a good argument or I'm missing something.

Released under CC0.

[wbinnssmith]

It's also worth noting that this depends on the metadata changes introduced in atom/atom#15383 -- though I think this shouldn't be an issue with future releases of command-palette?

This looks similar to #90, but rather than having the user configure their command palette, the package author can determine whether their commands should be shown using the new metadata API. Both should be able to co-exist.

cc @jordwalke @t9md

[t9md]

I like this idea, but I want escape hatch.

I'm maintaining over 30 packages including vim-mode-plus.
Sometime I ask my pkg user to execute command via command-palette to determine issue is keymap related or not.
If execute via command-palette works but not via keymap, it simply keymap issue.
This situation frequently happen in different keyboard layout and this trouble shoot option was great help.

I want hide most of vim-mode-plus command basically, but I want to keep the way to "force show all commands by ignoring hide flag" option.

[jordwalke]

Perhaps it's a matter of naming hiddenInCommandPalette to something more like hiddenByDefaultInCommandPalette - then it's up to various command pallets to provide a way to "show all" (hopefully a keyboard shortcut or something).

[nathansobo]

I'm not completely opposed to adding an ability to hide commands, but I'm very concerned that it could create confusion and opacity about which commands exist. Do we have any more concrete examples of commands that most people would consider to be noise?

For the example of Vim Mode Plus: Set Input Character M, I'm wondering if this is more related to a problem of the command system being insufficiently expressive.

What if we enhanced the commands system in the following way:

• We enhance the key bindings system to always include the keystroke as a string-valued field on the command event in addition to the originalEvent field, which only provides the most recent raw keyboard event.
• When listeners are registered for a command, allow the registering user to specify a requestDetail: true field on the command specification. When the command palette detected this field, it would prompt the user with a text area if they selected that command.

If we did this, then Set Input Character could be a single command that you can bind multiple keys to in specific modes of vim-mode-plus. For the common keyboard use case, the package could just read the keystroke string off the command event. For the command palette use case, the user would be prompted to enter a string. Now there's one Set Input Character command instead of a zillion of them.

I'm not sure if this solution would apply to other examples of noisy commands. I'd love to hear some more you've experienced @wbinnssmith to confirm or deny this proposed solution.

I can anticipate some potential enhancement ideas to this proposal, like specified some sort of typed schema for the detail arguments. But I think as a first pass it could just always be a string and left to be parsed and interpreted by the package.

What do people think? @wbinnssmith? @t9md?

[t9md]

For the example of Vim Mode Plus: Set Input Character M, I'm wondering if this is more related to a problem of the command system being insufficiently expressive.

I think this is off-topic of original issue.
This command is just picked as one of many examples of noisy command.

In vim-mode-plus, for example each keystroke like j(move-down),k(move-up) have corresponding command.
But none of vmp user try to execute it from command-palette its always invoked via keymap.
So most of vim-mode-plus's command is just noise, no need to appear on command-palette.
vmp register over 300 commands at pkg activation.
This 300 command slow downs command-palette's response when you typed shift-cmd-p.
#81 is PR to solve this slow down issue by limiting maxResult of command-palette(which have it's own caveat that confuse user who doesn't notice this truncation).

Summary: most of vmp's command is noise, I think it's good if pkg author can control visibility of command on cmd-palette, it also reduce delay of cmd-palette.
But I want keep escape hatch for troubleshoot purpose.
E.g

1. when user execute Command Palette: Toggle Show hidden commands(which might change color of command palette to indicate command-palette is in-special mode need to be reverted after).
2. Then command-palette shows all commands including hidden one, which is useful to investigate keymap issue.(I want to ask user to check it work if executing from palette when they just reported that "X keystroke not work!").

[nathansobo]

@t9md That seems reasonable. Basically my proposal doesn't really fix the noise problem in a general way. I'm sold that we want to add hidden commands.

Is somebody willing to add @t9md's escape hatch of Command Palette: Show Hidden Commands (that just lets you fuzzy-find through hidden commands) to the default command palette? I can get it done eventually but am dealing with higher priority stuff so if someone could just do it I am down to merge a hidden by default, showable in rare situations approach.

[nathansobo]

@t9md @wbinnssmith I've added the suggested Command Palette: Show Hidden Commands escape hatch. Once we get a green build I will merge.

[nathansobo]

This is published as 0.42.0 (the answer to life, the universe, everything) and upgraded in atom/atom@3d3042b. Thanks again for making this change. Sounds like it will make life much easier for vim-mode-plus users once @t9md leverages it. 📈

[t9md]

Thank you!! I'll try.
Hope command palette's lag reported by vim-mode-plus user will be solved after that.

[t9md]

After I hide all vmp commands.
I quickly measure item population time as I did in #81.

collect + render equals to total item population time.

My summary is

• hiddenInCommandPalette is good to reduce noise.
• But not perfect solution to reduce command-palette's lag. I still feel big delay on opening palette by cmd-shjift-p.
  • I don't think asking all pkg auther to hide their command is ideal or concrete solution.

Then how to solve palette's delay(my thought)?

• Still setting maxResults is effective to greatly reduce delay by reducing items to render further.

  • But this approach really confuse user.

• Better approach is to postpone full item population until some scroll event(??) is fired.

  • First populate top 20th items.( we can get stable response time regardless total num of registered commands ).
  • When user try to access more items via mouser or core:move-down, it render full items.
  • So as long as main usecase is open > filter by querly(keyboard) > concifm, user no longer find palette's delay.

[UziTech]

Another approach could be to allow the user to hide certain commands. Something akin to the way the user can disable the keymaps of a package could be useful.

I know there are only a handful of commands that I actually use so hiding the rest by default could save a lot of time in the render process.

[nathansobo]

We need to just optimize the menu rendering. If anyone cc's me on a PR that does it I will prioritize working with that person and make a best effort to be timely. Otherwise it's something we'll need to put a full time engineer on at some point.

[Ben3eeE]

@nathansobo There is a PR open to only render elements when needed on atom-select-list. atom/atom-select-list#21

I believe this is what you are asking for?

[nathansobo]

Awesome, thanks for keeping track of so much @Ben3eeE. Love it. I responded there and hopefully can work with @jarle to push it forward.