Hi Luis, Luis Henrique Gomes Higino writes: > Hi Guix, Hi Pierre, > > I apologize for my delay, the last few weeks were quite busy :-/. No worries! :-). > > Pierre Langlois writes: > >> I'm sharing it early as a WIP first, as I just noticed the other day >> that Luis also contributed a patches for tree-sitter for neovim[0]. The >> series I have here is quite a lot bigger though so I'm happy to rebase >> it on top of yours, Luis :-). The package I had for tree-sitter looks >> basically the same, I would then move it to a new file with all >> tree-sitter related packages, if you're happy with that. > > That's OK by me! > >> So I'm wondering, are these tree-sitter grammar packages also useful for >> the neovim package for tree-sitter? > > I'm not exactly sure about this. Currently, most Neovim users install their > grammars through the installer included in > https://github.com/nvim-treesitter/nvim-treesitter. That ensures > the user gets the version that is ABI compatible with nvim-treesitter. That > makes me uncertain if we could use the same grammar packages for Neovim and > Emacs, at least for now. I see, I suppose for the moment we're not packaging nvim-treesitter so we don't have to concern ourselves with how language grammars are delivered to users. In the future it might be cool to package it, out of curiosity I took a look at it and it: - [0]: Clones the repo with `git'. - [1]: Run `npm install' and `tree-sitter generate'. - [2]: Compiles the generated grammar with gcc. [0]: https://github.com/nvim-treesitter/nvim-treesitter/blob/90485c890503f973271db1ae02ddba6d6fd46397/lua/nvim-treesitter/install.lua#L378 [1]: https://github.com/nvim-treesitter/nvim-treesitter/blob/90485c890503f973271db1ae02ddba6d6fd46397/lua/nvim-treesitter/install.lua#L228 [2]: https://github.com/nvim-treesitter/nvim-treesitter/blob/3aac7f9db9ee1973152426c097216e0071dd2293/lua/nvim-treesitter/shell_command_selectors.lua#L96 The only concern I can think of is that when it runs `npm install', it's likely that it downloads a `tree-sitter' binary, rather than use Guix's tree-sitter-cli package. In my series I had to patch package.json files for each grammar to remove `tree-sitter-cli' as a dependency: https://github.com/tree-sitter/tree-sitter-c/blob/e348e8ec5efd3aac020020e4af53d2ff18f393a9/package.json#L20 Otherwise it would pull in the official tree-sitter-cli node package, which then downloads a `tree-sitter' binary :-/ https://github.com/tree-sitter/tree-sitter/blob/master/cli/npm/package.json Anyways, I don't think that's something we should concern ourselves with for now. If we ever want to package nvim-treesitter, I think we might have to patch it so it uses Guix-provided grammars instead of building them locally. For emacs that wasn't so difficult to do, but the real issue is making sure the grammar is compabible, and luckily the emacs package had tests we could run for that. We would also need to run tests if we're to package nvim-treesitter. > >> I do wonder if I'm going about it the right way for Guix though, for >> instance I'm wondering if I should rewrite the grammar packages using a >> new custom build system, do people think it would be worth it? That >> could be done as a follow-up of course. > > I'm not a very experienced packager myself, but from what I saw in your patch, > it seems rather unnecessary, as the grammar packages are very simple. That was also my impression :-). Since then I did play with building one to see what it would look like, also as an escuse to go and learn how they work. I'm still on the fence about it though, I've attached what it could look like, if anybody else is also unsure. I think I'd prefer to work on it as a potential follow-up after an initial set of patches get merged. Thanks, Pierre