nvim-ts-rainbow2 VS mini.nvim

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).

This is essentially a tagline of mini.move.

Just as the others suggested, oil.nvim solves this outta the box. I freaking love it (here my config in case ya need it). Apparently also mini.files handles this by default

You mean backwards seeking text objects? You can get those with mini.ai https://github.com/echasnovski/mini.nvim/blob/main/readmes/mini-ai.md

I would like to offer you to join me in saying late greetings to this autumn with a release of mini.nvim version 0.10.0. It is mostly about introducing three (quite feature full, dare I say) modules and minor updates of existing ones.

Last night I cleaned up all the dead code in my config and realised that mini.nvim has to be the single best plugin that I've used. I have a couple of other favourites but this collection has been so consistently good that I wanted to give some thanks to the juggernaut that is u/echasnovski! Thanks for all the work you plugin authors and core maintainers put in to make this editor what it is <3

For example: I spent a lot of time configuring file tree plugins to have the same sorting as VS Code, tweaking their icons, etc. But then I realized I barely used the file explorer at all, and now I'm super happy with the minimal approach of mini.files. I had similar experiences with other plugins that were just adding "fluff" instead of the functionality I was looking for.

Around two weeks ago I've announced the release of mini.files - a file explorer module of mini.nvim with column view navigation and "edit text to manipulate file system" design. This resulted into a great feedback from the community, much of which turned into new features.

A mini.ai textobject specification that you can use standalone