Hotkeys: display command ID (with component/plugin namespace) and make it easier to search plugin hotkeys (plugin-name:hotkey-name)

Use case or problem

Currently, the hotkeys panel works this way:

  1. it shows a readable name (that I will call command title below to match VS code naming), prefixed by "[Plugin]: " if it belongs to a plugin (but not prefixed for core components like “editor” and “workspace”). Namespaced command name used in code such as “table-editor-obsidian:evaluate-formulas” (which I will call command ID below) are not shown
  2. you can search a command by title, but you must enter a (case-insensitive) substring of the title (you can start and end midword, but cannot skip word nor do fuzzy search)
  3. you can search a command by ID, but you must start with the exact ID (case-insensitive though) which is formatted: “[component/plugin-name-with-hyphens]:[base-command-name-with-hyphens]”. Using spaces won’t work, and starting with base command name without prefix won’t work

  1. if you open the list or core or community plugins and click the (+) button to open the list of associated hotkeys, the search field is prefilled with “[plugin]” (but not “[plugin]:”)

This causes some issues:
a. because of 2., when searching command by title such as “Add file property”, “Add property” will show nothing
b. because of 3., when searching command by ID such as “markdown:add-metadata-property” (which is the ID for Add file property), typing “add-” won’t even work
c. because of 1., user cannot learn command IDs either unless they set a hotkey and look at the VCS diff of hotkeys.json. Sometimes, hyphenating English name works, but often, the ID is different. For instance, “markdown:add-metadata-property” for “Add file property” and “daily-notes:goto-next” for “Daily notes: Open next daily note”, which is hard to guess. It is even worse for core component hotkeys because the English readable prefix (e.g. "Markdown: " isn’t shown, so you cannot even attempt an English to hyphenated string conversion). And as noted in b., because of 3., you need to know the prefix for a command ID search
d. because of 4., you are tempted to add more words after “[plugin]” using a space, such as “[plugin] [command 1st word]” but because of 3., this doesn’t work

Proposed solution

A. For the command ID issue, I suggest displaying the command ID below the command title in the same way as in VS Code


B. For the search, there are various ways to solve this, but overall I think VS code’s approach is quite good:


i. you can search by command title, skipping any character. It’s not full fuzzy in the sense that you cannot type a character that doesn’t exist in the original string order, but otherwise it’s quite loose: you can chain characters that are normally separated, without using a space.
ii. you can also add 1+ space(s) to indicate a new word (whether a true new word in command title, a new sub-word marked by an upper letter in command ID, or a word completely on the other side of the dot that separates namespace in command ID).

For instance, “edi fl” will match “editor.folderLevel1”, “…Level2”, etc. but also editor.action.goToFocusedStickyScrollLine.

iii. bonus: VS code even supports swapped word order

For instance, “level fold” will also find “foldLevel” commands and “edi fl” will even find “workbench.action.focusLastEditorGroup”. We don’t need to go that far for now, though, I just want to avoid getting 0 results as soon as I hit space.

Current workaround (optional)

  1. Search command by title e.g. “Add file property”
  2. Modify hotkey
  3. Check VCS diff of hotkeys.json to learn command ID
  4. Next time, search using full command ID with namespace

Looks like editing was locked after 10mn or so, preventing me from posting better screenshots. So you have a screenshot right between 3 and 4 but it should be after b.

Here are the other screenshots:

For a:

For c:

P.S.: if you edit your post and click Save Edit after passing the max delay, you will get an error “An error occurred: You are not permitted to view the requested resource.” which is not clear. Unfortunately it must be related to the forum framework so forum managers can probably not do much about it. If they could extend to edit time to longer, I would be grateful (1h, or why not, infinite? unless there have been cases of abuse, but that’s harder if you keep a history of changes? It works fine on StackExchange, and it’s useful to fix and update question later, sometimes based on other people’s answers).