Just chiming in, have just struck this bug as well - shortcut keys (Cmd E, Cmd B, Cmd Enter etc ) when used for a note in the sidebar are applied to the last focused pane in the main area. Annoying because I’ve moved all my “management” daily/task list notes and so on into the sidebar so I can minimise it away and have my real work front and center.
because that arrangement/workflow would be ideal for me to maintain focus on actually working. Workaround is to have a second workspace with the daily setup present, but that’s annoying because I have to update it every day with the new daily note.
EDIT: had the thought that maybe I could trigger the commands via the palette and that might work - have just tested trying to set selected text to bold, and it doesn’t work either, same behaviour as with the shortcut keys.
EDIT #2: On OSX 11.1, Obsidian 0.10.1 Installer 0.9.17
I think this issue likely arises from the fact that app.workspace.setActiveLeaf() does not support setting a sidebar document as the active leaf, and presumably commands are always applied to the active leaf.
Specifically, setActiveLeaf() checks whether the new leaf’s getRoot() is equal to the workspace root, but a sidebar document’s getRoot() is the top-level split of its associated ribbon.
ISTM setActiveLeaf() should be checking for rightSplit and leftSplit as well as rootSplit. I’ve tested this with a quick monkeypatch from the developer console, and it allows both commands and hotkeys to work, and also allows the cycle-through-panes plugin to cycle properly, even cycling through the sidebar documents.
There does seem to be one other glitch that it doesn’t fix, though: toggling the edit mode of a sidebar document causes the first pane in the main split to become active. Clicking again in the sidebar document returns it to an active state, however.
There is also no visual indication that a sidebar document is active, and activating a document whose tab isn’t selected doesn’t cause that tab to become selected. Similarly, selecting the tab of a sidebar document doesn’t cause it to become active.
So, it looks like more work will be needed to fix this besides just making it possible for a sidebar pane to be set active… although just supporting that would be a big help.
While investigating this issue I also discovered why the history behaves so oddly in 0.9.x; it apparently includes navigation between panes as part of the history. It sounds like that might have been changed in 0.10.x, though.
Create 2 new notes.
Open both of them up.
Drag one into one of the side panels.
Focus the note in the side panel.
Try editor shortcuts (e.g. bold, delete line, etc) or the same shortcut form the command palette.
Editor commands are only apply to the panel in focus regardless of where it’s placed.
Actual result
Commands are applied to the last focused editor that is not in a side panel at the last place the cursor was focused regardless of whether an editor is focused in the side panel.
Environment
Operating system: Windows 10
Obsidian version: v0.12.3
Additional information
Strangely as you can see at the end of the recording, copy/paste do work correctly.
Just a quick note on this… it’s basically because setActiveLeaf() explicitly doesn’t allow leaves to be active if they’re in a side pane. At one point I played around with having pane-relief patch it to allow sidebar panes to be active, but I ran into some difficulty with the question of whether moving to the “next” or “previous” panes should include the panes in the sidebars, and if so, which ones, etc.
Anyway, the majority of commands in Obsidian do something to the “active” pane, and since sidebar panes can’t be “active”, that produces this result.
(What I don’t know is why they’re specifically disallowed from being active.)
This is a very annoying bug. Is there any chance the Obsidian devs could implement @pjeby’s fix by patching setActiveLeaf() as described above, even if it’s not a perfect fix? Or is this something that could be done with a plugin? I’d love for command-return etc to work properly in my sidebar notes…
Still experiencing this bug in Feb 2022. I hope there’s a resolution soon! It seems like hotkeys should be applied to any pane/file in which the cursor is active/blinking.
move file a to be part of the right pane. I.e. having a fixed position underneath the other standard panes (tag, backlink etc)
open file b
move the editor focus to fixed file a (in order to edit it)
press CMD+ENTER in order to insert “- [ ]”
observe that the task notation is actually being added to file b
Expected result
If a file is a fixed part of the right pane, then executing CMD+ENTER will actually put the task notation in that file
Actual result
Executing CMD+ENTER in the right pane fixed file, will insert the task notation in an active other file.
Environment
Operating system: MacOS
Debug info:
SYSTEM INFO:
Obsidian version: v0.14.0
Installer version: v0.13.31
Operating system: Darwin Kernel Version 21.3.0: Wed Jan 5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_X86_64 21.3.0
Login status: logged in
Catalyst license: insider
Insider build toggle: on
Live preview: on
Legacy editor: off
Base theme: dark
Community theme: none
Snippets enabled: 0
Safe mode: off
Plugins installed: 5
Plugins enabled: 0