nvim-ts-rainbow2 VS lemmy-help

You should continue with the fork nvim-ts-rainbow2 instead. But I also have the same problem. The colors are not updated instantaneously and sometimes pairs are mismatched. But most of the time formatting the file works fine. Other times simple :e solves it certainly.

Author of nvim-ts-rainbow2 (fork of the aforementioned nvim-ts-rainbow) here.

If you are afraid of missing something, then I recommend you to put all public symbols in one file. For example, in nvim-ts-rainbow2 the file lua/ts-rainbow re-exports symbols from private modules for public use. Whenever I add a new symbol to the table I know I have to document it.

I was using a recent fork of it from 'mrjones2014'. Now I tried https://gitlab.com/HiPhish/nvim-ts-rainbow2 too, still the same issue random order in different files. So weird :(

for the past few days I have been working on a fork to the nvim-ts-rainbow plugin: nvim-ts-rainbow2. I am pretty much done, except for one small issue: finding out the level of a node relative to other container nodes. I know how to determine the level of a node in the tree (just keep counting up from 1 while going through the parents until I hit the root), but that is not what I need.

Do you have any concrete plans on what you want to change? I have created a fork as well, but one which intends to overhaul the code quite a bit. See the TODO file for an overview (some of it is already implemented).

I have now forked to incorporate my ideas. The key idea is to abstract away the concept of a "strategy", which is to say how to perform the highlighting. The default strategy for now is the global highlight in which the entire buffer is lit up like a Christmas tree. The next strategy will be like in the PR above to highlight only the current sub-tree that contains the cursor (see video in linked issue).

So let me tell you about my experience! In the stone ages of lua plugins, I was maintaining a markdown file to note down all the APIs but as the plugin was constantly changing, docs were getting out of sync very quickly and it was a royal pain to update them. So, in my case emmylua was the obvious choice for the docs, so I began searching for tools that convert emmylua to vim-help, luckily I found tree-sitter-lua#docgen and mini.doc. But in the end, I decided to write my own tool, and thus lemmy-help was born. Here a help file generated by it

When I added some EmmyLua docs to one of my plugins (to generate Vimdoc using lemmy-help), I noticed lua-language-server was giving me diagnostics based on my documentation. This was something I was not getting from linters like luacheck. So I asked myself, "Can I leverage lua-language-server and EmmyLua to statically type check my Lua code?"

This will drastically improve the UX of help files. I am adding support for this in lemmy-help here https://github.com/numToStr/lemmy-help/pull/65 and I hope other doc generators can leverage this to provide beautiful help docs :)

If you want to provide vim doc, I recommend to use lemmy-help as soon as possible.

Rust is great for parsing text. I created https://github.com/numToStr/lemmy-help to parse emmylua from lua code and convert it into vim help doc. I am also reading https://craftinginterpreters.com/ to expand my parsing knowledge and using Rust as the implementation language.

I just released lemmy-help v0.8.0 which now has support for all* emmylua types. That means you can use any complex types in you emmylua annotations and it will be parsed correctly and vimdoc will be rendered as expected

And if you are writing lua plugin which have public API, I would recommend writing emmylua and covert that into vimdoc using https://github.com/numToStr/lemmy-help (Self Plug)

multiline ---@field description

I've just released https://github.com/numToStr/lemmy-help :)

That's just too much. You can just download the binaries from the releases page https://github.com/numToStr/lemmy-help/releases