Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Neovim installation #141

Open
mrdgo opened this issue Nov 15, 2024 · 2 comments
Open

Neovim installation #141

mrdgo opened this issue Nov 15, 2024 · 2 comments

Comments

@mrdgo
Copy link
Contributor

mrdgo commented Nov 15, 2024

There is now this. A config and highlights for tree-sitter-nu within nvim-treesitter.

Currently, - following installation/neovim.md - we override both, namely the config in plugin/init.lua and queries in queries/nu/*.scm.

plugin/init.lua also sets up filetype detection, which we might also be able to get upstreamed to neovim itself.

Then users would not have to install this repo as neovim plugin, see

{ "nushell/tree-sitter-nu", build = ":TSUpdate nu" },

in installation/neovim.md, probably saving users some diskspace but, more importantly, also supports installing nu support via just :TSInstall nu, without any additional line of configuration.

However, as it currently is, we have the advantage that we manage our queries/nu/*.scm ourselves. So we can easily make braking changes - i.e., renaming or removing nodes that queries refer to - because we directly control both, the grammar and the highlights. With a transition to the nvim-treesitter, we have to be careful whenever we do one of the two changes to our grammar, because we have to adjust queries in a different repo.

I hope that I made the situation clear to everyone who uses this parser in neovim.

@fdncred
Copy link
Collaborator

fdncred commented Nov 15, 2024

I'm not sure really what you're suggesting. We haven't transitioned to nvim-treesitter. Someone else has taken it upon themselves to do that. I hope they maintain it.

@mrdgo
Copy link
Contributor Author

mrdgo commented Nov 15, 2024

No real suggestion, just bringing up an issue. And oof, I hoped that the person got in touch with anyone here. Hmm, that person has to update queries whenever we update them.

The transition should be a goal of this parser. Personally, I would want to wait until we have a 1.0 nu and a feature-complete parser. Because maintaining will become more difficult, when we need to sync multiple repositories.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants