Hi! I've found that Neovim upstream force-enabled treesitter for some filetypes. For example, it was enabled for lua on Jan 1: https://github.com/neovim/neovim/commit/f69658bc3. Also, there are also `vimdoc` and `query` parsers enabled (and as nvim buildsystem also fetches `c` and `vim` parsers, it is possible they'll enable that parsers too in near time) But: 1) we don't have `lua`, `vim` and `vimdoc` parsers (grammatics) in gentoo repo (but I already made ebuilds for them localy and will push them in near time) 2) neovim searches for them in another path, and by another names than we install them: - we install them as `/usr/$libdir/libtree-sitter-$name.so` (like `/usr/lib64/libtree-sitter-json.so`), - and nvim searches them as `/usr/$libdir/nvim/parser/$name.so` (like `/usr/lib64/nvim/parser/lua.so`) As `vimdoc`, `lua` and `query` parsers are mandatory now (otherwise even `nvim --clean` throws an error on startup when opening lua file), we'll anyway need to do something, as it will definitely trigger on next release (0.10, I guess) and make nvim unusable for users. At first, I had thoughts about a following ways to fix that: - add some code to neovim-9990 ebuild, with creating `/usr/$libdir/nvim/parsers` (as it doesn't exist by default with our installations), and `ln -s` tree-sitter parsers there with correct (for nvim) names (and also make nvim depend on all the parsers that upstream force-enabled) // although, that looks dirty, imho - add new package like `nvim-tree-sitter-parsers-rt` and create corresponding symlinks there, and make nvim depend on it instead. And in that case, should we depend (and make symlinks) on all parsers (grammars) we have packaged, or all installed, or, again, only the ones currently force-enabled on upstream and keep an eye on upcoming force-enablements? Then @sam suggested to speak to upstream first, and ask if they can add additional search paths. I'm pretty sceptic about they answer, but I asked them on GH (will add a link in "See Also"), so let's see. Also @sam suggest to add additional path (probably, with symlinks to original libs), like /usr/$libdir/tree-sitter. And, as I found later, this is exactly the way alpine does (will also add a link to "See also"). And if we'll go this way, I think we wouldn't need to do anything at upstream, but just symlink `/usr/${libdir}/tree-sitter` to `/usr/${libdir}/nvim/parser` and be happy. Reproducible: Always
Well, BZ don't acccept alpine packages liks to See also, so here it is: https://pkgs.alpinelinux.org/contents?branch=edge&name=tree%2dsitter%2dlua&arch=x86_64&repo=community
Created attachment 882375 [details, diff] fix finding luajit in live @Vadim we have seen this issue before, @Sam had helped me fix this but I'm not sure how this commit got lost/reverted. Can you please try out this patch and see if the live ebuild is buildable.
(In reply to listout from comment #2) > Created attachment 882375 [details, diff] [details, diff] > fix finding luajit in live > > @Vadim we have seen this issue before, @Sam had helped me fix this but I'm > not sure how this commit got lost/reverted. Can you please try out this > patch and see if the live ebuild is buildable. Please ignore this commit I meant to comment in bug#922138
