Offload UI to render-markdown.nvim

[MeanderingProgrammer]

🚀 The feature, motivation and pitch

Hi, I own the render-markdown.nvim plugin, which is focussed on rendering markdown files inside Neovim.

I recently became aware of this plugin and while I'm not too familiar with it at this point in time it appears there is a good amount of overlap in how the UIs function, with custom checkbox states, bullet points, anti-conceal behavior based on cursor row, etc.

If I had known of this plugins existence I might not have created my own, it does a lot of what I was looking for. But since I don't use obsidian and only wanted a UI I didn't check this one out :(

However given where we're at my proposal is to offload / remove the UI logic from this plugin and use render-markdown.nvim as a dependency to handle this. If there are missing features I can work on adding them. If there's any interest in this I am definitely open to talking it through in more detail.

I completely understand the many reasons why you would not want to do this. From the loss of complete control over the UI layer to just the fact that it's already built and adding a dependency at this stage is more trouble than it's worth or any other completely valid reason. Absolutely no hard feelings if this is a non-starter.

At the same time their is the potential to offload any UI related feature work / issues and focus on other parts of this project.

Looking forward to hearing back, thanks for the consideration!

Alternatives

The 2 plugins continue to live separately

Additional context

Some of the obsidian like features, primarily custom checkbox states require neovim 0.10.0 for my implementation.

The plugin in general works for any version >= 0.9.0, but with fewer features.

I thought this was of note given the 0.8.0 compatibility of this plugin.

[JamiroFerrara]

I am currently using both markdown.nvim for markdown rendering and obsidian.nvim for functionality. So this would be a welcome change.

[pachungulo]

I am currently using both markdown.nvim for markdown rendering and obsidian.nvim for functionality. So this would be a welcome change.

I too would like to do something like this. In your experience, has there been any loss of functionality in obsidian.nvim by switching rendering to markdown.nvim? Is it basically just a straight upgrade to the UI?

[AquilesGomez]

I haven't experienced any loss in functionality

[rstacruz]

has there been any loss of functionality in obsidian.nvim by switching rendering to markdown.nvim?

markdown.nvim doesn't support [[wikilinks]], so far that's the only loss in functionality I know.

[MeanderingProgrammer]

Added support for wikilinks: https://github.com/MeanderingProgrammer/markdown.nvim/commit/e6695b4ff330cf9c216fe5e40491cee39d93383a

Raw View	Rendered View

[MetinYalcinkaya]

I am currently using both markdown.nvim for markdown rendering and obsidian.nvim for functionality. So this would be a welcome change.

I too would like to do something like this. In your experience, has there been any loss of functionality in obsidian.nvim by switching rendering to markdown.nvim? Is it basically just a straight upgrade to the UI?

Frontmatter doesn't seem to show links properly with just render-markdown, but that is just specific to Obsidian's markdown files.

[theherk]

This would be great, or at least an option do disable rendering features done by obsidian.nvim. I use obsidian, so otherwise need this for note management, but prefer render-markdown in all other cases. The problem is that enabling both at the same time causes some weird behavior. Like concealing more than expected. For example,

- [x] #tag Some task item. 📅 2024-09-02
- [ ] #tag Some other task item.
- [ ] Yet another task item.

is rendered (with both) as:

I didn't make it back to edit my comment before @yongleyuan pointed out my mistake. 😄 Yes, I had just discovered that, and it works great. Perfect. Thank you.

[yongleyuan]

@theherk You can already do that by disabling obsidian.nvim's UI as noted in render-markdown.nvim and obsidian.nvim:

require('obsidian').setup({
    ui = { enable = false },
})

[guoliang]

@theherk You can already do that by disabling obsidian.nvim's UI as noted in render-markdown.nvim and obsidian.nvim:

require('obsidian').setup({
    ui = { enable = false },
})

doesn't seems to help. this is my minimal configuration for epwalsh/obsidian.nvim plugin

    opts = {
      ui = {
        enable = false,
      },
    },
    config = function(_, opts)
      require('obsidian').setup(opts)
    end,

afterward doing `checkhealth render-markdown

render-markdown.nvim [conflicts] ~

• OK headlines: not installed
• WARNING obsidian: installed
  • ADVICE:
  • Ensure UI is disabled by setting ui = { enable = false } in obsidian.nvim config
  • Acknowledge conflicts to avoid this warning by setting { acknowledge_conflicts = true }

[yongleyuan]

@guoliang I think the warning message will always be there if you have obsidian.nvim installed (please correct me if I'm wrong). Please check if obsidian.nvim's UI is truly disabled by observing whether the UI is handled by obsidian.nvim or render-markdown.nvim (again please let me know if there are other ways to check, but I think the differences are quite obvious, eg: checkboxes).

[guoliang]

@yongleyuan, yea it seems like disabling UI in the obsidian.nvim indeed does what it does. I suppose it is up to render-markdown.nvim to fix so that checkhealth doesn't give out a false positive warning

[MeanderingProgrammer]

@yongleyuan, everything you said is correct thanks for helping out!

@guoliang, I've updated the health check logic to avoid the warning if the obsidian UI is disabled: https://github.com/MeanderingProgrammer/render-markdown.nvim/commit/4d2aea341a5d0bf2a01adc0ad4ecf5d4877e1bd0

Previously you could avoid the warning by setting acknowledge_conflicts to true, but the new mechanism is better IMO and automated. Though it is fragile to changes in obsidian.nvim.

[einarpersson]

I followed the advice here and found render-markdown.nvim and obsidian.nvim a fantastic combination, so I hope that compatibility will remain (and think the idea presented in this issue sounds wise, although i respect the plugin author if he/she differs).

[btctrl]

yes i agree, i just wasted an hour (my own fault) realizing that these two plugins conflict when trying to debug a bullet point padding issue only happening in my vault md files