Filetype list as config option

[serhez]

From what I understand, the plugin only works with md files. Could there be a filetypes list in the config where users could add other filetypes to use the renderer? For example, Quarto (qmd), Jupyter Notebooks (ipynb) or R-markdown (rmd) files.

Thanks for the plugin! :)

[OXY2DEV]

As much as I would like to there are a few problems.

The main problem will be the treesitter parser. If you have a different filetype than markdown it will say something along the lines of.

Treesitter-parser for <filetype> isn't installed

Which is going to stop the entire plugin.

But if you change the filetype then plugins(& other functionalities) may break. Sometimes you won't even notice that something isn't working properly.

Another issue would be clashing with other(similar plugins), a lot of people tend to already use some sort of plugin(and people don't like to stop using the tools they are familiar with) for these filetypes. And frankly it's impossible for me to ensure everything works everywhere.

The third issue would be automation. I have seen other similar plugins automatically set themselves up(and there's a PR for it already). And I am considering about adding it.

[serhez]

Thanks for the quick reply :)

For the treesitter parser, if I had the Quarto parser installed, for example, would it give me the same error? Is the issue that users would need to install the parsers for the filetypes they use?

I'm currently using headlines.nvim and it is able to work with Quarto files, which is what I mostly use. For Quarto, I also use the official quarto-nvim plugin and also magma-nvim to run code blocks. headlines.nvim does not interfere with them, they coexist together. Of course, this plugin may do different things than headlines.nvim, but perhaps stating in the README something like "Use with other filetypes and in combination with other rendering plugins at your own risk" would suffice?

[serhez]

Also, since the plugin is already broken down into individual features in the config (e.g., lists, headers, code-blocks...), maybe each of these rendering features could be enabled/disabled in the config. In this way, if e.g., code-blocks are rendered wrong because some other plugin is interfering, users can decide to individually disable that feature to make all their plugins co-exist. I'm not sure if implementing this would be hard as I haven't dived deep into your code. Just throwing some ideas.

[OXY2DEV]

For the treesitter parser, if I had the Quarto parser installed, for example, would it give me the same error? Is the issue that users would need to install the parsers for the filetypes they use?

It completely depends on the parser. For example you can use something like (comment) @match to search for comments. The problem is that not every parser will mark comments with the comment node. So, in that case that query will fail(resulting in the plugin crashing).

And not all features are available on every parser so some changes will need to be done to use them.

There are other stuffs but I won't bore you with it.

If you look at the source code for headlines.nvim you will see it has dedicated files just for a specific filetype.

Which basically means that I will have to rewrite the entire thing(or some parts of the plugin) every time I want to add support to a new filetype.

I will also need to handle edge cases(e.g. something at the start/end of the buffer, stuff near the edge of the screen etc.) which are very hard to track.

---

So, it's not on my bucket list for now since learning new treesitter parser's nodes takes a bit of time and I am a bit busy now.

I will probably check it out later but no promises.

[OXY2DEV]

Also, since the plugin is already broken down into individual features in the config (e.g., lists, headers, code-blocks...), maybe each of these rendering features could be enabled/disabled in the config. In this way, if e.g., code-blocks are rendered wrong because some other plugin is interfering, users can decide to individually disable that feature to make all their plugins co-exist. I'm not sure if implementing this would be hard as I haven't dived deep into your code. Just throwing some ideas.

Yes, this is planned. I will add it in the next update.

[serhez]

Ok, I see! It's unfortunate the parsers don't follow the same conventions.

[OXY2DEV]

Also, since the plugin is already broken down into individual features in the config (e.g., lists, headers, code-blocks...), maybe each of these rendering features could be enabled/disabled in the config. In this way, if e.g., code-blocks are rendered wrong because some other plugin is interfering, users can decide to individually disable that feature to make all their plugins co-exist. I'm not sure if implementing this would be hard as I haven't dived deep into your code. Just throwing some ideas.

Update on your request: It appears that this is quite a bit tricky.

As you can see I have a link in a table

Here's how it's meant to look like.

The problem is neovim(& most likely vim too) automatically conceals them(the conceal feature is currently used by block quotes and a few other things) so to make it look like the text hasn't shifted I have to add spaces to the cells.

If I add enable/disable to all the options, this will not work. And the logic for it will become even more complicated which is a bit unfortunate.

[OXY2DEV]

Feature enable/disable was added to the main branch. You can test them out now.