[Bug]: (2.0) Formatting commands not available in command palette

[pjeby]

[Bug]: (2.0) Formatting commands not available in command palette

[mgmeyers]

Ah yes. Obsidian was clearing activeEditor because it expects the active editor to be in a MarkdownView. Should be fixed in the latest release

[pjeby]

If you mean 2.0.28, the hotkeys now don't work for me at all, even after restarting Obsidian. 😢

I'm not sure what's up here -- it looks like a plugin interaction of some kind, but turning on the same plugins in sandbox doesn't seem to recreate it? Ah, it's plugin order related - if Kanban is the last-activated plugin it doesn't work.

It looks like the issue is that it's monkeypatching Workspace.prototype, but that's an antipattern for patching existing instances in Obsidian with around(), at least until every plugin using monkey-around is on version 3.0+ (which supports chaining to the prototype from an instance). So your patch never actually runs if you're using any plugins that patch the Workspace instance before you (that aren't themselves on monkey-around 3.0).

So you can either patch the instance directly (app.workspace instead of Workspace.prototype), or you could maybe just use the active-leaf-change event? Your patch isn't checking that the active leaf is in fact the leaf it was passed in, or interupting the normal process in any way, so it'd probably be better to use the event -- especially since it the event fires after any and all setActiveLeaf monkeypatches.

[pjeby]

It now works in current beta. Thanks!

I still strongly suggest using the active-leaf-change event, though, or accessing the active view instead of the passed-in leaf, since it is not guaranteed that a successful return from setActiveLeaf() actually sets the supplied leaf as the active leaf. (Pane Relief's focus lock function, for example, blocks certain changes to the active leaf, and I'm not even sure that Obsidian's API has any guarantee about that. It'd also let you drop the code duplication from Obsidian core.)

Using the active view lets you do less fiddling with details of Obsidian internals, too, e.g.:

    this.register(
      around(this.app.workspace, {
        // eslint-disable-next-line @typescript-eslint/ban-ts-comment
        // @ts-ignore
        setActiveLeaf(next) {
          return function (...args) {
            next.apply(this, args);
            const view = this.getActiveViewOfType(KanbanView);
            if (view?.activeEditor) {
              this.activeEditor = view.activeEditor;
            }
          };

And the above's even simpler if it's just an active-leaf-change event listener. But either way, using the active view ensures this won't conflict with anything that blocks or redirects the active leaf assignment.

[mgmeyers]

Thanks @pjeby! Forgot to reply to this. It turns out that active-leaf-change isn't called every time setActiveLeaf is. Specifically, if setActiveLeaf is called with the currently active leaf, then workspace.activeEditor will be set but active-leaf-change will not be triggered. This results in the Kanban plugin's editor from being cleared out of workspace.activeEditor every time the leaf is clicked.

Good idea about using this.getActiveViewOfType. That does seem like a better approach.

[pjeby]

Cool. Out of curiosity, why is the @ts-ignore needed? Is there some typing I'm missing that should be in monkey-around, or is it just that setActiveLeaf has multiple overloads and TypeScript is kinda dumb about overloads? 😉

[mgmeyers]

Yeah, that latter. I was too exhausted at the time to figure out why typescript didn't like the overloads 😮‍💨

[pjeby]

Yeah, one of the big TS gotchas around function signatures is that there are lots of places where TS silently punts to "use the last overload instead of checking them individually, because that should be general enough for everything, why not!". (The other fun one is where you want a callback to take specific arguments, and it says, "well, this function doesn't take any arguments, so that should be even better, right!")

Anyway, just wanted to be sure it wasn't an issue with monkey-around. I suspect the reason I haven't run into that on setActiveLeaf yet myself is that I haven't upgraded the Obsidian API version in some of my plugins for a year or two. 😁