> On this note, I think there's room for an open source pluggable PKM as an alternative to Obsidian and think Zed is a great candidate. Unfortunately I don't have time to build it myself just yet.
I'm also super interested in building this. OTOH Obsidian has a huge advantage for its plugin ecosystem because it is just so hackable.
One of the creators of Zed talked about their experience building Atom - at the time the plugin API was just wide open (which resulted in a ton of cool stuff, but also made it harder to keep building). They've taken a much stricter Plugin API approach in Zed vs. Atom, but I think the former approach is working out well for Obsidian's plugin ecosystem.
I'd argue their current plugin API model is far too strict. It only supports 4 things: theming the GUI (color+alpha changes only), adding tree sitter grammars, adding a language server, and adding "slash commands" (which seems to be a defunct prior experiment).
Notably it does not include the ability to add any features, or configure any settings.
In VSCode the block edit function and multi-cursor weren't part of the original tool, but were available as extensions. While Zed has that particular feature right out of the box, there's no ability to add features like that via extensions in Zed.
Also, Zed doesn't even seem to have the concept of per-buffer settings or "effective" settings that differ from what's on disk. It's why you can't set tabs vs spaces for indentation in a single buffer, you can only set it globally (for example). That's probably why they don't allow extensions that do things like add predefined key maps, or associate new files with a language (without defining a new grammar), or apply a pre-defined set of settings automatically (E.g. autodetect indentation type? Vim/Emacs modeline parsing?). Almost all of even the simplest VSCode, Emacs, and Vim/Neovim extensions/packages/plugins make use of this concept, which is why it's wild Zed doesn't even (seemingly) have the concept of it, let alone allowing extensions to use it.
In fact, I'd argue Zed doesn't actually have an extension system at all. It has a completion system (LSP servers), a language addition system (tree sitter grammar and/or LSP server), and a themeing system. It just combines all three into a single list it somewhat misleadingly calls "extensions". But it's missing the ability for "extensions" to do any of the most basic things every other tool assumes is table stakes for an extension system.
I'm also super interested in building this. OTOH Obsidian has a huge advantage for its plugin ecosystem because it is just so hackable.
One of the creators of Zed talked about their experience building Atom - at the time the plugin API was just wide open (which resulted in a ton of cool stuff, but also made it harder to keep building). They've taken a much stricter Plugin API approach in Zed vs. Atom, but I think the former approach is working out well for Obsidian's plugin ecosystem.