Tag completion support

[dawsers]

Hi, thank you for the great LSP server! It is really fast, and I am hoping it will provide a full solution for markdown/obsidian editing in Neovim. I have been using it for a couple of weeks, and there are two things I find missing:

1. Tag auto-completion: I use tags extensively, and marksman and obsidian.nvim both have tag auto-completion. I understand it should be a relatively easy addition, as moxide already supports go to tag definitions and references, so they are parsed.

2. Bug: I think moxide parses anything starting by # as a section-type entry. However, it doesn't check whether the symbol happens within a code block. For example, when I ask for document symbols for this small document (sh fenced code block), I get comment lines as sections.

# Real Section

# Just a comment
cd ..

I would get both Real Section and Just a comment as document symbols instead of just Real Section.

Thank you very much for your work.

[Feel-ix-343]

Thank you for your comment! Community-reported issues are so important (more than my crazy ideas!)

1. Tag completions should work. Here is a gif showing them off (here is my nvim config too)

Please let me know how you are triggering the completions and also make sure that you have configured nvim-cmp as specified in the readme. Also make sure that you have the latest version as things have been changing quickly. We should be able to figure this one out!

2. You are so right that code blocks are being taken into account. I have not written the code for this, and will fix it soon Parse code blocks #7

Again, thank you so much for the comment! I hope we can fix these issues soon. I would hate not to have tag completions 😄

[dawsers]

You are totally right!. I had remanents in my config of when the name was obsidian_ls, and instead the nvim-cmp part was using markdown_oxide.

I am sorry. This can be closed. Thank you again!

[Feel-ix-343]

I should have made an announcement when I renamed it! But I just thought that nobody was using actually using this 😆 Im sorry!

Also, I really want to standardize the nvim-cmp config. I knew it would be an issue from the beginning.

I can either make an nvim plugin for markdown-oxide but this adds an install step, which I dislike) or I may be able to figure out a way to configure nvim-cmp from nvim-lspconfig (which I already have a WIP PR up for here), but I don't even know if lspconfig would allow me to configure other plugins from within theirs.

Do you have any thoughts or preferences regarding this?

[dawsers]

I think you did the right thing taking the standard path. cmp-nvim-lsp has a default keyword_pattern trigger, and LSP servers that need a different one should override it, like you wrote in the README. It was my fault not to update it. And now that the name will be stable, it shouldn't pose any problems for new users.

I think you are also right about not adding a Neovim plugin. It should be a different project if anyone wants to add functionality around it. I don't like all-in-one too complicated solutions despite good intentions from the developers. For example, obsidian.nvim provides very good stuff, but it tries to do everything. The problem is when something doesn't work well, or doesn't fit someone's needs, either you take it all or cannot use it. The same goes for bugs, it can become unmaintainable. That is where I find markdown-oxide very interesting, I can have my own functions for things like managing the vault, creating notes etc.

I like the modularity your project provides: a good LSP server compatible with cmp-nvim-lsp. Then I can write a few small functions for additional features within any editor ecosystem.

I am very happy to be able to move to markdown-oxide.

[Feel-ix-343]

The same goes for bugs, it can become unmaintainable

Ooh great point!

I like the modularity your project provides: a good LSP server compatible with cmp-nvim-lsp. Then I can write a few small functions for additional features within any editor ecosystem.

I am very happy to be able to move to markdown-oxide.

Thank you that means a lot.

One more thought: leaving the configuration to the user means that when/if I update the keyword pattern (which is not impossible), the user would need to make a manual update, which is not ideal. This is why I am in favor of trying to configure nvim-cmp through lspconfig; it would update when the plugin manager updates.

It is nice to know that configuring the keyword is not such a burden though!

[sQVe]

I think you are also right about not adding a Neovim plugin. It should be a different project if anyone wants to add functionality around it. I don't like all-in-one too complicated solutions despite good intentions from the developers. For example, obsidian.nvim provides very good stuff, but it tries to do everything.

I wholeheartedly agree, which is why I've been working on https://github.com/sQVe/notebox.nvim. Notebox.nvim aims to help you manage Markdown-based notes, providing recommendations for companion plugins to create your own note-taking environment.

---

@Feel-ix-343 I will add markdown-oxide as a strong recommendation in ☝, once I can find some time to actually finish the documentation 🙈

[anandkumar89]

I don't like all-in-one too complicated solutions despite good intentions from the developers. For example, obsidian.nvim provides very good stuff, but it tries to do everything.

functionalities in obsidian.nvim are limited to searching notes, completion for wikilinks, completion for tags. Allows renaming files. native vim commands as gf are allowed to go through linked files.

In these terms I believe markdown-oxide have caught up fair bit. Even closer to the obsidian core linking feature.

@dawsers not sure what is complicated or do it all about obsidian.nvim though. Strongly feel that efforts in these two repos are put in almost same direction, although m-oxide can be generalized to multiple editors.

[dawsers]

When I wrote that comment, obsidian.nvim was trying to provide completions, like you say, using ripgrep in the note repository. That was one of the things I found "too much", because that kind of task is better suited for an LSP server like markdown-oxide or marksman, which can do it much more efficiently. Of course my comment was in no way against obsidian.nvim which I personally have found very useful, and even contributed to it in a very small way. It seems in the end they plan to collaborate with markdown-oxide and divide responsibilities, which to me makes total sense.

[Feel-ix-343]

not sure what is complicated or do it all about obsidian.nvim though. Strongly feel that efforts in these two repos are put in almost same direction, although m-oxide can be generalized to multiple editors

This is all true; the other thing about a language server however is compatibility with the neovim language server ecosystem. Inherently obsidian.nvim would need to build in support for pickers (telescope), while this language server has and will have support for any picker created - eg I currently use a combination of Lspsaga, telescope, and nvim-navbuddy.

I'm also really seeing the importance of this merge, and I will be working on it in the shortterm