vimPlugins.nvim-treesitter-legacy: init

[PerchunPak]

This is a straight-up copy of our nvim-treesitter directory. For now, it is identical to the main package, but #470883 will update vimPlugins.nvim-treesitter to the newer version.

After trying to use #470883, it is clear to me that migrating is not easy. There is even no migration guide because of how different those two versions are. Users (and plugins) need more time to update

I propose deprecating nvim-treesitter-legacy right before 26.04, then dropping it after 26.11, together with all non-updated plugins.

I am not sure whether we want to keep updating grammars for the legacy version, or not touch that directory at all. We agreed to keep grammars frozen

Warning

This should be merged at the same time as #470883, because the neovim wrapper: throw if two versions of nvim-treesitter are present commit will break everything, when there is no difference between the legacy and new version.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[khaneliman]

After trying to use #470883, it is clear to me that migrating is not easy.

I'm curious what parts you use that are not clear from their README. I created nix-community/nixvim#4084 in nixvim for migrating from master to main and it seemed pretty straight forward for the base functionality. Some things used to be handled by the plugin have been upstreamed to neovim and just require you to do outside of the plugin config table for starting the highlighting/indenting/etc. I did not have a very big treesitter config though so didn't need to mess with much.

I do know there are FEATURES that are missing with the rewrite, though... like incremental selection and treesitter-refactor plugins because of the API changes.

Reading through some of the removed functionality and the "work in progress" on ancillary projects that depended on the current "master" API does make this have value, though.

I propose deprecating nvim-treesitter-legacy right before 26.04, then dropping it after 26.11, together with all non-updated plugins.

What does "non-updated plugins" mean ? There are many plugins that don't need to keep pushing new versions because they are API stable and "just work".

I am not sure whether we want to keep updating grammars for the legacy version, or not touch that directory at all.

No, this should be a frozen in time thing like upstream is treating it, imo.

[khaneliman]

mawkler/demicolon.nvim#14 seems to imply that this plugin works with main branch

[khaneliman]

ray-x/go.nvim#592 implies it is tested/works with main now.

[khaneliman]

Only uses get_indent from nvim-treesitter https://github.com/pta2002/intellitab.nvim/blob/main/lua/intellitab/init.lua#L29-L31 and that exists on main https://github.com/nvim-treesitter/nvim-treesitter/blob/4fc09bee78e91bf4ba471cdab4bf9dfa37fde51c/lua/nvim-treesitter/indent.lua#L112

[khaneliman]

This one is actually depending on a migration mistweaverco/kulala.nvim#790 https://github.com/mistweaverco/kulala.nvim/blob/9fc4831a116fb32b0fd420ed483f5102a873446a/lua/kulala/config/init.lua#L49

[khaneliman]

https://github.com/ggandor/leap-ast.nvim hasn't been updated in 3 years and isn't compatible (ts_utils doesn't exist in main)

Requirements

Neovim >= 0.7.0
[leap.nvim](https://github.com/ggandor/leap.nvim)
[nvim-treesitter](https://github.com/nvim-treesitter/nvim-treesitter) (This dependency is only temporary; it will not be necessary in the future.)

[PerchunPak]

Should we drop it?

[khaneliman]

Might be best, it doesn't look active (could be because it used to work well for its purpose) and if they haven't updated to the new api by now, people might not be using it anymore / maintaining it.

[khaneliman]

I think the configs table is missing in main https://github.com/David-Kunz/markid/blob/9b249e4d2ad0767a1091017cd52264590e41a274/lua/markid.lua#L2-L3 so this might need update. Hasn't been updated in 2 years though

[khaneliman]

This plugin was already updated to support main branch https://github.com/fredrikaverpil/neotest-golang/blob/37e400cfe9d193e508b1a512e96cbef83b08deb6/README.md?plain=1#L9-L13

[khaneliman]

This is still in process of migrating to main NvChad/NvChad#3313

[khaneliman]

This plugin has NOT been updated to work with new API.

[khaneliman]

This plugin has NOT been updated to work with new API.

[PerchunPak]

We should really merge this as soon as possible, otherwise we break 12 out of 19 plugins that depend on nvim-treesitter (12 plugins still depend on the master branch, others are updated)

[ojsef39]

I really want to see this getting pushed forward, as my whole nvim config is now broken since nvf doesn't support the new treesitter yet and i did some upsis and now its pretty hard for me to just rollback :/

So i trusted the commit comment and tried to override it, just to notice that the legacy package is not there yet.

Thanks in advance and hope you had a good start into the new year! :)

[mrcjkb]

issue: nvim-treesitter-legacy has lots of queries in its runtimepath.
They will conflict with the nvim-treesitter main queries.

As the current most common use case is for people to pull in nvim-treesitter-legacy as a dependency of another plugin, this can break things in subtle ways that may be difficult to troubleshoot.

We should probably remove the queries from nvim-treesitter-legacy and make them opt-in.

[PerchunPak]

There is a check if two different versions of nvim-treesitter are installed
31d10c1

Also, even if someone tries to install a plugin with a parser from nvim-treesitter main, but has nvim-treesitter.withAllPlugins, the parsers should still be compatible, as we used the list of those from main branch long before release

[mrcjkb]

The queries and parsers are now decoupled. What if someone wants to install the parsers and queries without nvim-treesitter?

the parsers should still be compatible, as we used the list of those from main branch long before release

You mean the main parsers should still be compatible with the nvim-treesitter-legacy queries?
That's not going to be guaranteed for future updates. The nvim-treesitter-legacy queries are frozen, the parsers aren't.

[PerchunPak]

Well, I can remove old parsers and only use the new ones, which should solve compatibility issues. But this minor use case should not block this PR. Currently, most of the plugins that use nvim-treesitter are broken. I can create a follow-up PR, but I do not want to change this, so no one has to re-review it.

[mrcjkb]

You mean the queries?

[PerchunPak]

Checking if the user has duplicated queries from the main and master branches is impossible because we symlinkJoin those. So the only solution would be to get rid of both old queries and parsers

Deleting one of those doesn't really make sense because, as you said

That's not going to be guaranteed for future updates. The nvim-treesitter-legacy queries are frozen, the parsers aren't.

[mrcjkb]

So the only solution would be to get rid of both old queries and parsers

That's what I'm proposing (and yes, it's fine if we do this in a follow-up PR).

The only reason configs are breaking is because plugins rely on the old module API, which is Lua and should have no compatibility issues with the new queries or parsers (unless, the capture names for indents, etc. change, which I think is unlikely to happen anytime soon).

Long term, we should aim to fix upstream plugins that depend on nvim-treesitter-legacy to depend on treesitter-modules.nvim instead.

[Elias-Graf]

Update:

Ah it appears that I need to switch:

-          require('nvim-treesitter.configs').setup { highlight = { enable = true } }
+          require('nvim-treesitter').setup { highlight = { enable = true } }

As described in: nvim-treesitter/nvim-treesitter#7901 (comment).

At least I don't get an error at startup now, I haven't done any further testing.

PS:

Maybe also relevant: nvim-lua/kickstart.nvim#1732 (comment)?

---

Sorry for intruding your pull request, I started getting:

Error detected while processing /home/elias/.config/nvim/init.lua:
E5113: Error while calling lua chunk: /home/elias/.config/nvim/init.lua:227: module 'nvim-treesitter.configs' not found:
        no field package.preload['nvim-treesitter.configs']
        no file '/nix/store/ppkk2jsl4yahrm0bwrlggkaki826x6q6-luajit2.1-nvim-web-devicons-0.100-1/share/lua/5.1/nvim-treesitter/configs.lua'
        no file '/nix/store/8p012cx5h66v6s3664fav3cgkn3mqnp5-luajit-2.1.1741730670/share/lua/5.1/nvim-treesitter/configs.lua'
        no file '/nix/store/kbgkach2vy5wwx25iq3nq4wvawpr0wvq-luajit2.1-plenary.nvim-scm-1/share/lua/5.1/nvim-treesitter/configs.lua'
        no file '/nix/store/kbgkach2vy5wwx25iq3nq4wvawpr0wvq-luajit2.1-plenary.nvim-scm-1/share/lua/5.1/nvim-treesitter/configs/init.lua'
        no file '/nix/store/s16704aclkb8ksqfjz86ymfylm7ks7cq-luajit2.1-luassert-1.9.0-1/share/lua/5.1/nvim-treesitter/configs.lua'
        no file '/nix/store/s16704aclkb8ksqfjz86ymfylm7ks7cq-luajit2.1-luassert-1.9.0-1/share/lua/5.1/nvim-treesitter/configs/init.lua'
        no file '/nix/store/6mqd7avxcvy7b4yk375ippqyswyc3jzp-luajit2.1-say-1.4.1-3/share/lua/5.1/nvim-treesitter/configs.lua'
        no file '/nix/store/6mqd7avxcvy7b4yk375ippqyswyc3jzp-luajit2.1-say-1.4.1-3/share/lua/5.1/nvim-treesitter/configs/init.lua'
        no file './nvim-treesitter/configs.so'
        no file '/usr/local/lib/lua/5.1/nvim-treesitter/configs.so'
        no file '/nix/store/8p012cx5h66v6s3664fav3cgkn3mqnp5-luajit-2.1.1741730670/lib/lua/5.1/nvim-treesitter/configs.so'
        no file '/usr/local/lib/lua/5.1/loadall.so'
        no file './nvim-treesitter.so'
        no file '/usr/local/lib/lua/5.1/nvim-treesitter.so'
        no file '/nix/store/8p012cx5h66v6s3664fav3cgkn3mqnp5-luajit-2.1.1741730670/lib/lua/5.1/nvim-treesitter.so'
        no file '/usr/local/lib/lua/5.1/loadall.so'
stack traceback:
        [C]: in function 'require'
        /home/elias/.config/nvim/init.lua:227: in main chunk

Is this related? I've read something about migrations, but I'm not sure what I would need to change. My config for treesitter is just:

      {
        plugin = nvim-treesitter.withAllGrammars;
        type = "lua";
        config = ''
          require('nvim-treesitter.configs').setup { highlight = { enable = true } }
        '';
      }

[PerchunPak]

@Elias-Graf, this is because nvim-treesitter was entirely rewritten, and we recently switched to the new version. This is not a bug. But in the future, please open an issue instead