Currently, if a hotkey has a conflict there’s a good chance it will not work at all, despite there being situations where it’s fairly tame to have a hotkey do a similar action but in different situations. The example that inspired me to write this was trying to map Alt+Arrow to moving table rows/columns around using the new built-in table editor, only to find that it conflicted with the shortcut to move lines up and down, which I had already assigned. These two features ostensibly do the same thing in raw markdown, but it’s fairly intuitive to separate when I might want one or the other. In the Live Preview editor, elemental actions like reorganizing a table or list (c.f. Outliner plugin) are more likely what the user is trying to do over the raw action of line manipulation. This gets me thinking that adding contexts to assigned hotkeys might be a useful way to solve a lot of conflicts.
The gold standard for what contextual shortcuts involves is something like VSCode, where the many boolean context identifiers associated with the current focus can be granularly adjusted and applied to commands by users, with support for boolean and set-like logic. I assume this would be a momentous undertaking to implement in Obsidian, so for now, I wonder about the implementation of the simple analog of just an Editor Mode context.
If I could assign shortcuts to specifically Live Preview, Source, (and even Reading) mode, I could more efficiently utilize shortcuts where it’s more obvious to me what sort of action I’m looking for. I could use Move line only in Source mode, and Move row, etc. only in Live Preview. And maybe, in Reading Mode, the same shortcut could instead move pane focus, scroll the view, etc.
I envision adding a datum to each assignment that specifies what Mode it’s associated with and possibly adding color based on mode. It wouldn’t have to be a multi-select modal, instead users would select only one context for a given assignment, and only if two assignments use the same hotkey in the same mode would a conflict error arise.
Looking to the future, I could see hotkey contexts extend to things like “am I in a table environment?” or “am I in a codeblock?” (with language-aware context enabling a language-aware Toggle Comment command, for example), but of course happy to Keep It Skeptically Simple.
I’ve also come up against this problem and it would definitely be helpful! Another example is when using excalidraw, I can’t use existing hot keys for excalidraw commands despite them having no other possible view to act on.
I want to quickly and comfortably delete a note while navigating the folder structure
Proposed solution
The most intuitive solution would be to enable binding of Delete or Backspace hotkey to the action of deleting a note. However it is not possible currently as explained here:
The way to make it possible would be to introduce context for hotkeys. If the context is “editor” then Delete would remove a character in the editor, but if the context is something else, like “shell”, “navigator”, or “container”, then Delete would delete the current note.
Current workaround (optional)
One can assign Cmd+Delete, but a single key binding would be more comfortable and intuitive.
There are valid usecases when a user might want to assign conflicting hotkeys.
One example is for opening the file explorer view and also revealing the currently opened note inside the file explorer:
A nice workflow to always show the currently active note, unless there’s none opened, then just show the file explorer.
I don’t know how the commands with conflicting hotkeys are handled currently. Maybe it’s based alphabetically, because the Files: Show file explorer command always takes precedence in this case.
Proposed solution
I think the the logical thing would be that the conditional commands that can’t be executed anywhere should take precedence over general commands when there’s a hotkey conflict.
Another example: Merge selection and merge entire file. A Nice workflow would be to execute the merge selection command, which is conditional based on if any text is selected and otherwise execute the “merge entire file” command.