Something in nixCats is messing with nvim-orgmode highlights

[eldritch-cookie]

I recently decided to try nvim-orgmode/orgmode and for some reason with nixCats even after commenting out my whole init.lua and disabling all plugins except orgmode i still have no highlighting even though using :Inspect and :InspectTree works.

I know that this is likely nixCats related and not the plugin's fault due to using my old nixvim configuration with orgmode added, highlights work fine with the same orgmode version. Another thing which indicates the plugin doesn't have issues is that calling require("orgmode.colors.highlights").link_highlights() restores all highlights

yes i can call that in a ftplugin, however i still would prefer to know what is causing this as there may not be a workaround next time.

[BirdeeHub]

It is likely that the nixpkgs treesitter changes are messing with it from when they rolled over to the new treesitter

That plugin contains queries and a parser for treesitter.

However the parser isn't built and included in the repo you would have to build it or otherwise install it separately.

The issue is honestly likely to be with whatever this is in nixpkgs

It appears to be designed to make it so that the parser is automatically included without you needing to install it separately.

But due to the new treesitter updates, that snippet may not work as expected anymore. Or maybe something else is going on, not sure.

It is very unlikely to be a nixCats specific issue. Maybe if you were using lazy.nvim it could be an issue with the helper wrapper for it which one can pull and put in their config, but it does not seem you are.

But it may be a nix specific issue.

This is because nixCats literally takes whatever is in the plugin derivation and links them to pack/myNeovimPackages/{start, opt}/<name> on the packpath. If the thing in that derivation can be installed by nvim as a plugin it will work as well as whatever is in it works, and otherwise it will not. It also processes the same attributes the nixpkgs one does on the plugins to gather dependencies that nixpkgs maintainers have specified.

Treesitter grammars and queries also work this way, as long as the parser is at parser/<name>.so and the queries at queries/<name>/

However, if something has been passed through pkgs.vimPlugins.nvim-treesitter.grammarToPlugin it will also collate them into 1 directory for performance. That function is designed to take parsers, and put them in parser/<name>.so, which means they collate cleanly. Collation in this case means "put them in symlinkJoin".

You can turn this collation off, but it is not the issue here because this one has not been passed through that function and the heuristic to detect that does not match for this plugin, so that is also unlikely to be the issue, all it does with this plugin is link it there.

---

If you move to my new (better) neovim wrapper (which is part of a more generalized wrapper script creation project using the module system), it works basically the same there.

I would very highly recommend checking it out over using this project, both because it is much better and has better integration with the ecosystem and does a lot more than just neovim, and also because I wrote both of them and am moving my focus to the new one.

However I would be quite surprised if this issue was specific to either project. It should happen with the nixpkgs nvim wrapper and all other such things as well. The logic in nixCats for building the packpath is based off of how they do it in nixpkgs, and it still does the same thing and is fully compatible with what they do there. In the new project as well, it does all the same stuff, just slightly differently so that you can do placeholder "out" and impure paths.

It is also possible that your lua config for treesitter just hasn't been correctly updated to the new scheme, and you have something which tells it not to use the treesitter highlights? But that wouldn't be something coming from nixCats either

---

A good rule of thumb for things which may be related to nixCats:

If it is related to where vim.fn.stdpath('config') is pointing (also true of other wrappers). Stuff usually only grabs this path to write to it, so it points where it usually does outside of the store. You will want to configure that to point at the unwrapped version of your config most likely.

If the problem is that something is being collated with the grammars that shouldnt be, or is not but should be (you can go look at the packpath in the store to see if this is the case, the location is in your info plugin)

If it is something that is happening because you are using a wrapper script at all.

If nixpkgs adds a new value you can define on nixpkgs neovim plugins, and that value is not being processed (although that is a new feature and will not be addressed here, and in the new one you can collect them yourself if you want, but I may add the option for it to the default setup for that in the new one anyway)

Anything else and its most likely the definition of whatever you are adding from nixpkgs.