-
-
Notifications
You must be signed in to change notification settings - Fork 161
Support nvim-treesitter's parser_install_dir configuration #967
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
Comments
I'm trying to use this plugin but it fails to install the treesitter org parser. The nix store is read only so nvim-orgmode fails at the install. Allowing us to handle this dependency on our own would be great! Also I looked at what I think is the org parser but it is archived? Is this the current parser that is used by orgmode? |
This is the official parser being used: https://github.com/nvim-orgmode/tree-sitter-org/tree/next I'm not sure how nix works, so I'm open for suggestions, as long as it does not involve adding a dependency on nvim-treesitter. How are you installing other parsers? |
I've been installing tree-sitters parsers via nixpkgs; We don't have to use the nixpkgs repo though, we could build the parser as a flake output. Then anyone who wants to use the orgmode parser could bring it in as a flake input. They would handle the parser dependency on their own. Then we would set an environment variable for orgmode to look for. If it finds that environment variable it would use the parser at that location instead of attempting to install on its own. Or we could allow for a global variable to be set. I'm not good with Lua, working on learning it. I can try writing a flake.nix file for the tree-sitter-org repo. That would be the first step. |
I'm ok with using nixpkg. We probably need a github action to publish to nixpkg. Since I have no idea how it works, can you create a PR on https://github.com/nvim-orgmode/tree-sitter-org with the setup? You can follow luarocks release to figure out how to get necessary data for publishing, like version, etc. Once we do that, I'll figure out a way to handle this separately installed parser, since now I expect it to be installed in the orgmode/parser/ folder. Does that sound ok? |
That sounds great! I'll see if I can get that done today. I'm looking into norg's implementation and using it to see what a proper implementation looks like. |
Any updates on this? |
There is now a pull request to update the tree-sitter grammar to the correct version here I also plan on creating a pull request that introduces an overlay to the parser. None of this will resolve the issue with orgmode attempting to install the parser on it's own though. Will need to point the plugin to the already compiled parser somehow |
Once the version is updated I'll update the code to not require a parser to be located in the orgmode folder. That should solve the issue. |
In my configuration I am able to build tree-sitter with the grammars I would like to use. This means that by the time the setup function for orgmode gets called there is already a compiled org.so library. This path on my system contains all the parsers installed on my system.
If I could point orgmode to that directory it would find the org.so file. Perhaps a new configuration option in the setup function for orgmode could achieve this? |
Is this path part of your |
That's a good question. I'm new to Lua and neovim so take what I say with a grain of salt. All I know is that when I perform a healthcheck on tree-sitter it shows the org parser as OK. I'm guessing that if tree-sitter can find it all right then it should work fine with orgmode? |
You can check by doing I'll be updating the logic around this in the following days to not require the parser to be in the orgmode folder. It will still notify if there is more than 1 org parser found, but that should not happen if you load the parser before the orgmode is loaded. |
Oddly enough, if I symlink the orgmode's |
I'll update the installation during the weekend to allow for any location for the parser. That should solve most of these issues |
I updated the treesitter installation logic to not require the parser to be installed in orgmode folder. Released in 0.6.0 version. Let me know if that fixes it for you. |
@kristijanhusak still doesn't work:
It seems some codepath still tries to write a lockfile? And just for the record, that's with org grammar installed as per
|
@farcaller what about |
|
The problem here is because you expect the orgmode's plugin root directory is in user's $HOME somewhere, but in nix it's in the global and very read-only store. |
Yeah it did. Just pushed fixed to master. Can you give it another test? |
It loads without issues now! But now we're back to this problem: #967 (comment). There's no syntax highlighting whatsoever. |
Do you get anything from this command when you run it from the opened org file?
Also, do you have to do something around queries for nvim-treesitter? |
I do:
Which seemingly comes from nvim-orgmode/tree-sitter-org. |
I released |
That seems to do the trick, thanks! And thank you so much for all the debugging effort on this! |
Awesome! So there's no need for any monkey patching? |
Yep, it all works as expected now and the highlights are pulled from the correct place:
It's still somewhat strange they both aren't being pulled in, but whatever, it all works as intended now. I am currently not in a position to submit new packages towards nixpkgs (it's complicated), but I expect that to change soon-ish, so if no one else beats me to it I'll work on adding both. |
Does this feature exist in Emacs orgmode core?
N/A
Orgmode link
No response
Feature value
Currently, the orgmode plugin always installs the org parser to its own package directory ([package_root]/parser/org.so). It would be beneficial to respect nvim-treesitter's parser_install_dir configuration when available, which would allow users to keep all parsers in a single consistent location. This is especially useful in setups where the plugin is being installed by nix.
Additional context
No response
The text was updated successfully, but these errors were encountered: