I’m a plugin author (not a professional developer), so please excuse any incorrect terminology. I’m running into what seems to be a core/API gap: when explorer/navigation-style plugins and custom-view plugins coexist, some leaf scenarios can spiral into repeated open/reopen loops (flicker, focus jumps, runaway leaf/tab creation, and sometimes freezing). Right now the only practical workaround is monkey-patching, which is fragile and can make behavior inconsistent across different explorers/entry points.
Context (my usage model)
My plugin (TileLineBase) uses normal .md files as the data container — no dedicated frontmatter schema and no custom file extension — so it doesn’t fit a “bind file type to a default opener” model. Users toggle the same file within the same leaf/tab between the default Markdown view and a custom viewType via commands/hotkeys.
Problem pattern (plugin-agnostic)
Explorer/navigation-style plugins commonly initiate open actions (e.g., openFile/openLinkText). In some cases (leaf reuse failures, pinned/non-reusable leaves, reopen logic, etc.) they “recover” by retrying, reopening, or creating a new leaf.
If another plugin switches the leaf to a custom viewType after open, and there is no core-level, consistent extension point/contract to express “this open should be handled by the custom view”, it can form a loop:
-
the navigation plugin initiates an open and expects a state it recognizes,
-
the custom-view plugin switches the leaf to its own view,
-
the navigation plugin interprets this as “not opened correctly / wrong state” and retries (reopen/new leaf),
-
resulting in flicker, focus jumps, growing leaf/tab counts, and sometimes freezing.
Why this is hard to solve reliably in plugins
Current workarounds often rely on monkey-patching (intercepting open behavior, hijacking click handling, etc.), which:
-
depends on internal implementation details and breaks easily across updates,
-
creates inconsistent behavior between the built-in explorer and third-party explorers,
-
can escalate into “mutual correction”: one plugin interrupts, another compensates more aggressively, worsening the outcome.
This seems better addressed by a core mechanism rather than a single plugin overriding default behavior.
Minimal request (keep it small & stable)
Could Obsidian provide a core-level, consistent open/navigation extension point so custom-view plugins can declaratively handle certain open requests (without monkey-patching), reducing reopen storms?
A minimal, robust direction could be:
-
a core open/navigation hook where plugins can return “handled / I will handle this” (or provide a viewType / leaf-policy suggestion); and
-
deterministic single-handler arbitration: for any single open/navigation request, only one handler should be allowed to “win” (based on user preference / priority rules), avoiding races between plugins.
I’m not asking for “any plugin can intercept everything”, and I’m not asking the core to track plugin internal state. The goal is a unified, predictable extension point that reduces uncontrolled reopen loops.
References / reproduction
I can provide a minimal reproduction vault and steps if needed.
- My plugin (TileLineBase): https://github.com/campfirium/obsidian-tile-line-base
- Related forum topic (default explorer / routing): https://forum.obsidian.md/t/set-default-file-explorer-internal-or-plugin-like-notebook-navigator/108593
- Related third-party explorer discussion: https://github.com/johansan/notebook-navigator/issues/643
Thanks for reading — happy to clarify details or provide a minimal reproducible example.