help: rendering frontmatter like its done by obsidian.nvim

[LogicKahanHai]

Neovim version (nvim -v)

0.11.3

Neovim distribution

N/A

Description

Can someone help me setup frontmatter rendering like it's done by obsidian.nvim out of the box?

Obsidian.nvim

render-markdown.nvim

The main difference I want to cover through render-markdown is the underlining of links in the frontmatter and also the list. Concealing is way better in render-markdown so I want some way to keep using it but also have those little features in there. Is there some way to achieve this?

[MeanderingProgrammer]

This plugin doesn't supporting rendering frontmatter, outside of the dashed lines at the top and bottom.

The frontmatter sections are yaml blobs so in order to do this I would need to setup rendering support for an additional language. It could be done and if someone want to try implementing it feel free, it's not something I use so I don't know what correct rendering looks like.

I think the list item part would be fairly trivial so maybe I'll take a stab at that, but have no idea why Blog in your example should be interpreted as a link.

[MeanderingProgrammer]

Bullet point support added here: d7be79b

[LogicKahanHai]

I think the list item part would be fairly trivial so maybe I'll take a stab at that, but have no idea why Blog in your example should be interpreted as a link.

My bad for not explaining it properly. Actually that Blog is link to an empty file I use for logical separation of the notes into Types of Objects kinda like Capacities

It works, no doubt. because internally it is recognised as a link. it's just the appearance.

Also, I could not understand this from your comment

This plugin doesn't supporting rendering frontmatter, outside of the dashed lines at the top and bottom.

What I understood was that if I am using "another" frontmatter block (wrapped by ---) like aside from the one added by obsidian.nvim then it won't work. But, that's not the case I have disabled frontmatter in my obsidian.nvim config and I generate this frontmatter from a template the I have for Blog note types. Please correct me if misunderstood

[MeanderingProgrammer]

Actually that Blog is link to an empty file I use for logical separation of the notes into Types of Objects

So what I would need to know is the concrete and specific rules for how to identify links in yaml.

I can't interact with obsidian.nvim since I do not want to have brittle connections to other plugins. All I have is the parsed text, how do I tell from that where the links are?

Based on your example it is any text surrounded by quotes and double square brackets:

Object Type: "[[Blog]]"

What if I remove the quotes?

Object Type: [[Blog]]

What if the file in the link does not exist?

Object Type: "[[Does Not Exist]]"

Does it matter how nested it is?

Object:
    Type: "[[Blog]]"

If you can tell me that information and any other potential caveats I can give implementing it a try.

What I understood was that if I am using "another" frontmatter block (wrapped by ---) like aside from the one added by obsidian.nvim then it won't work

That's not quite right. I meant when you have frontmatter previously this plugin would add a dashed line at the top and bottom of the block (over the --- lines), but would completely ignore all the text inside. So previously that block of text inside --- was not touched at all by this plugin.

I have updated this (in d7be79b), so now this plugin will look inside that block and attempt to render bullet points for lists. Every additional bit of rendering needs a custom implementation, there is no overlap with the existing markdown rendering logic though we can re-use configurations like I did for bullet points.

[LogicKahanHai]

So what I would need to know is the concrete and specific rules for how to identify links in yaml.

Understood. Let me get back to you with the rules on Monday (IST).

I am very "very" new to Lua and I was looking into how you added support for bullets after my issue, I would like to try and add support the same way for other yaml related features, but I cannot promise a timeline for this as I am a student and I have some other priorities right now, I'll try to do it in my free time.

Here are some answers that I do know right now, I'll add the others and maybe correct some (if I am wrong right now) on the day I mentioned above.

What if I remove the quotes?

That would be an error because the types are fixed for frontmatters (as I observed in the Obsidian app NOT Neovim)
So, the initial check would be to identify the type of the data

What if the file in the link does not exist?

I see two options for this scenario.

• The best one imo would be to talk to an LSP (like marksman) and if it says file does not exist render it in red colour or if it is render it in blue (the colours are placeholders for the final highlight groups)
• To not care for it. Because the syntax is fixed [[]] in a string means the user is trying to link a file, so just render it like a normal file. The LSP that the user has configured (or some other way to navigate through links) will give them the error/way to create the file. (e.g. marksman-lsp gives an error for file not found. not in the frontmatter but in that case obsidian.nvim comes to the rescue when I try to go to that file, it asks me if I want to create it. My point - the "Not found" logic is available through other sources)
• Or maybe, we can just use the same logic of rendering the links that is being used in the normal markdown part of the file.

Does it matter how nested it is?

The frontmatter "should" not be nested. I will get back to you on Monday with the answer to "But what if it is?"

Meanwhile, I have one question - This added support for yaml, will it also be used in the code blocks for yaml files (like below)? or is it just for the frontmatter?

foo: bar

[MeanderingProgrammer]

Take your time, is no rush! And happy to take a look once you have something. A good chunk of that commit is doing setup for supporting yaml in general, after that it gets a little easier to add additional features, typically a query + an associated way to render the captured node.

To not care for it. Because the syntax is fixed [[]] in a string means the user is trying to link a file, so just render it like a normal file. The LSP that the user has configured (or some other way to navigate through links) will give them the error/way to create the file. (e.g. marksman-lsp gives an error for file not found. not in the frontmatter but in that case obsidian.nvim comes to the rescue when I try to go to that file, it asks me if I want to create it. My point - the "Not found" logic is available through other sources)

I like this option, communicating with LSPs to get information will make things more difficult in general and I'd need to handle potentially different ones. As a simple rendering plugin the intention is the user is adding a link so make it look like a link even if it's invalid. Similar to markdown links where I don't check that a URL or file actually exists.

Or maybe, we can just use the same logic of rendering the links that is being used in the normal markdown part of the file.

This isn't quite possible, we can use some of the configurations for it, like highlight group and icons, but the actual structure of a link in markdown is very different from this yaml version. markdown links have separate parts for giving links a visible title and a hidden actual URL.

By that I mean in markdown a link looks like:

[Blob](blog)

While in yaml it looks like:

"[[Blog]]"

So naturally the way you handle these has to be different, but I don't think it would be very complicated to do.

[MeanderingProgrammer]

Added support for one type of link, the one surrounded by double quotes and double square brackets, here: 146d4ff

Might not render the same way as obsidian.nvim, it uses the same logic as wiki link rendering in markdown. So adds an icon, hides square brackets, hides destination if there is an alias.

If there's any feature in particular you think is missing LMK!

[LogicKahanHai]

Amazing work!! Really! Thank you soo much!! ☺️
The frontmatter now already looks much more elegant.
Just one little request 🙃, it's perfectly okay if it does not go on your to-do list, if the wiki links could get an underline visually separate them from normal text, it would be perfect. I know I may be stretching it, forgive me for it 😁. I am very glad you were so quick with the fixes on my issue, thanks a ton! :)

[MeanderingProgrammer]

You're welcome :)

if the wiki links could get an underline visually separate them from normal text

Not out of the box but I added an option to make that possible here: ca86b59

The configuration would look something like:

vim.api.nvim_set_hl(0, 'underline', {
    underline = true,
})

require('render-markdown').setup({
    link = { wiki = { scope_highlight = 'underline' } },
})

Since the highlight group is applied over the link body you can use it to change the color or add other decorations by adjusting the options in the call to vim.api.nvim_set_hl, checkout :h nvim_set_hl() for more info.