Repository navigation
What would it take to use my lua grammar :) #543
Description
Activity
use #506 to install from local paths and generate from grammar or else just push it to your github repo
require "nvim-treesitter.parsers".get_parser_configs().lisp = { install_info = { url = "~/projects/tree-sitter-lisp", files = {"src/parser.c"} } } --require "nvim-treesitter.parsers".get_parser_configs().viml = { --install_info = { --url = "https://github.com/vigoux/tree-sitter-viml", --files = {"src/parser.c"} --} --} require "nvim-treesitter.parsers".get_parser_configs().markdown = nil require "nvim-treesitter.parsers".get_parser_configs().zig = { install_info = { url = "https://github.com/GrayJack/tree-sitter-zig", files = {"src/parser.c"} } } require "nvim-treesitter.parsers".get_parser_configs().kotlin = { install_info = { url = "https://github.com/QthCN/tree-sitter-kotlin", files = {"src/parser.c"} } }
#506 does you the favor of not deleting the parser repo after compilation which might be advantageous.
We can also make it the official one or use it as soon it is in some
nvimruntime path. You can set theused_by,filetypeoptions that some parsers already use. The query parser is for instance not used on normal scheme files but only on scheme files in subdirectoryparser.One question I had related to this. Any way to get the query files from the parser repo? I'd like to keep the files there if possible and iterate on them.
I think the easiest way would be to symlink them manually... We don't keep the parsers files around (to save some roome on users side).
@vigoux he wants us to adopt his queries. Just add a custom key to the parser info that we should copy the queries during installation (and add the necessary Lua code for this). Another possibility would be that to download the queries from his repo in the
write-lockfilescript so that whenever we bump the version of the Lua parser we import his queries.Should we provide facilities to install either version of the Lua parser (nvim-treesitter/tree-sitter-lua or tjdevries tree-sitter-nlua)?
If you make the language of your parser
nluaboth parsers you even co-exist (or better their queries). A setting could determine whether to load the one or the other.The trees generated by the
luaparser and thenluaparser differs by a fair bit, I think having them more close one to the other would be a good selling point (as switching from one to the other would basically be noop).I don't want them to be the same. I don't like the structure of the other tree. That's why I rewrote from scratch instead of forking and sending pr. Similar things are not grouped semantically IMO in the other grammar.
Right now we're going with switching to https://github.com/MunifTanjim/nvim-treesitter-lua, which looks to be a better parser for the "pure" language.
But since your parser is called
nlua, there is no obstacle to adding it as an additional parser for people interested in something especially tuned towards Neovim development. (It might be worth investing a bit of thought into how to make it easier to use one or the other parser, depending on filepath?)I've added this to the tracking issue so I'm closing this one; but feel free to continue discussing here!
Hi @vigoux :)
Just wondering what it would take to switch to this grammar: https://github.com/tjdevries/tree-sitter-nlua
I'd like to iterate on it and use it w/ tree-sitter, but it's pretty hard right now because of the default query appending and not using the same names...
If change the names of my repo would make things easy / you would accept it as the new lua grammar, I could do that. Just wondering what your thoughts are 😄