Builtin Obsidian LSP

[neo451]

I think the current of approach of providing completion sources is not sustainable. It is a lot of work debugging blink support, and potentially supporting other alternatives, like mini.completion and native omni complete.

This LSP approach solves it by spawning a in process LSP server (just a function) and lets the completion plugin to handle completion.

On top of that I also had some luck implementing a simple hover support to preview notes, I think zk-nvim has this but they need an external process and I think this one is much neater. (no shade

I think this opened quite nice space for new arrangement of functionalities.

currently ideas:

This PR:

• completion
  • basic wiki and markdown
  • blocks and anchors
  • should be aware of all the attachment filetypes in the vault feat: generic attachment filetype: drag n drop, opening #77
  • should have smart_snnipets: https://linkarzu.com/posts/neovim/markdown-setup-2025/#add-markdown-link-from-clipboard
• hover for previewing note content
• rename -> ObsidianRename
  • file rename
  • ref rename
• workspace_diagnostic ->ObsidianCheck
• code_action
  • should be a list of useful actions like quickswitch, dailies and extract note
• diagnostic
  • for things like orphan notes and dead links

Another PR:

Because this concerns making pickers lsp compatible:

• references -> ObsidianBacklinks
• document_symbol -> ObsidianTOC
• WIP document_link -> ObsidianLinks
  • neovim don't support this client ability yet, net to upstream.

let me know if there's more ideas!

[sotte]

This look interesting @neo451.

Thinking out loud to get a better feel for what this means:

If we decide to go down the lsp route, this would mean

• we remove all blink.cmp and nvim.cmp related code
• we just have have completion-framework agnostic code which would power the obsidian-lsp
• we can offer various obsidian commands via code actions (I really well integrated code action, e.g. these https://github.com/mrcjkb/rustaceanvim). Note that only relevant actions should be shown. This is better than the Obsidian* commands which you can always call, but some don't apply for the current situation.
• we need lsp experience to migrate everything and new contributors might shy away from contributing (maybe)
• we need to phase out the current approach and switch to the new one without breaking how ppl use obsidian.nvim

What are the must have features for the LSP?

• completion for tags and links
• some context specific actions
• hover

I suggest to have a concrete list of features that cover some of the more risky features as part of this POC PR. Then we can decide how to procced, i.e. if we want to replace the cmp stuff.

[neo451]

* we need lsp experience to migrate everything and new contributors might shy away from contributing (maybe)

I'll have to think more about other points like migration and a full feature proposal, but I can confidently say the lsp developer experience will be much better, the prototype completion logic is less than 100 lines and very readable, instead of needing to knowing specific plugin's API to do anything about it. I will also make sure to add documentation on how it works.

[neo451]

found a nice project for reference:

https://oxide.md/Home

[sotte]

Nice progress @neo451!

[marcocofano]

Hello, I have marksman installed and I am checking the features that are implemented there, already. How about references on links? Is there a way to list all the notes linking to the same note link under cursor?

[neo451]

will be easy to implement, ObdisianBacklinks already has the same logic I think

[DockterTeagle]

I, while perusing nixpkgs, found markdown-oxide, what are the possible features that this plugin would provide that this lsp server doesnt?

[DockterTeagle]

sorry that might have come off as hostile, I like this plugin but dont want people to have to reinvent the wheeel

[DockterTeagle]

after playing around with it this plugin supports the
[[ syntax from obsidian better. Maybe yall could instead extend this lsp server somehow? though the server itself is written in rust so that would only worsen the contributions problem that was mentioned earlier.

[neo451]

sorry that might have come off as hostile, I like this plugin but dont want people to have to reinvent the wheeel

I totally get the idea of not wanting to reinvent the wheel.

Some thoughts:

1. It would be less work (not necessarily faster though), a standard lsp server needs the client to send the document state through rpc to the server and maintain a document model in the server. But a in-process lsp server can just look at the document, which means just less chance of messing up, and just very easy to implement, essentially I am just rewriting existing functionality that we already implemented from scratch, but I just use the builtin lsp library, to do things like renaming, and completion. It is just much less code than the implementation now, and less code than any rust solution, in the meantime the the underlying functions are more reliable, ensured by the neovim team.
2. It would be more powerful, some examples:
   • Currently this plugin supports create note in completions, a traditional lsp server can not do something like this unless there's an companion plugin, since we need to run some lua code after the completion is accepted, this plugin is happy to provide callbacks for other markdown based lsps if they want.
   • I plan to add the reference system like obsidian app, where you type [^ and get completion to add a new footnote, this is all doable within the ability of lsp text_edits, but the obsidian app just does it smoother: it opens a small input window for you to type in the content of the footnote, and then insert the content at the bottom, this just beyond what a lsp protocol can do in my opinion, since user takes any amount of time to finish the content and then they expect the text edit to happen.

• more fancy stuff, the lsp can just call lua functions like the calendar app I am working on https://github.com/obsidian-nvim/calendar.nvim , if it sees a pattern like @, and spawn a calendar ui under the cursor like the calendar plugin for obsidian.

In conclusion, lsp is powerful for being editor-agnostic, but this plugin do not use it for that but for the great neovim lsp lua library. As a result, this plugin will have:

• better code maintainability, the functions are probably the simplest lsp code you can find out there
• more freedom and power to implement obsidian app features

and of course folks can just opt out of any feature they don't want and use other markdown lsps, we would be happy to make sure conflicts don't happen.