casouri
Add jq grammar by nverno
https://github.com/nverno/tree-sitter-jq
I'm not the author but it seems to work smoothly with tree-sitter-module.
I wonder if it is somehow preferrable to the one listed in this list: https://github.com/flurie/tree-sitter-jq
FWIW, the flurie one appears to be in use in nvim-treesitter.
Edit: Looking around a bit, it appeaars that the nverno one is used by jq-ts-mode by the same author.
Well this is awkward. But this repo being primary emacs-oriented, I guess we can go with the nverno one.
On a tangential note, I changed the name of one of the grammars I was working on so it wouldn't conflict with an existing one. This made it theoretically possible to use both grammars within one program "at the same time", so-to-speak.
May be it's worth reaching out to one or the other of the authors of the above grammars to consider the situation?
cc: @nverno, @flurie
I had initially used the same jq grammar as nvim-treesitter, but I decided to write a new grammar because the other one was incorrect in certain cases (eg. try clauses AFAIR) and caused excessive nesting (eg pipelines).
@nverno Thanks for the explanation.
I can relate to existing grammars not working as desired, as I was faced with a similar situation for tree-sitter-clojure (two other earlier attempts by other folks weren't working so well for me and fixing them didn't work out). In that case though, the earlier attempts had been abandoned so there was no issue with using the same name for a new attempt.
In another case (for the Janet programming language), by sheer coincidence, someone else had started on almost the same day, but we didn't know about each other's activities for some time.
We ended up taking somewhat different approaches -- in his case he tried to support things like defn, def, etc...whereas in my case I had already seen that being a significant issue for tree-sitter-clojure (too many misparses), so I opted for something simpler in scope.
My sense at the time was that for different goals one might want to use a different grammar (my attempt was more accurate AFAICT for getting an appropriate tree for things like structural editing, while his gives the functionality of recognizing more constructs).
However, for that to be possible within a single program it seemed that we needed to have different names for the grammars. I decided to rename my attempt so that it remained possible to use both grammars in the same process.
I don't know if there are other good solutions to situations like these. May be one idea is to discuss with the upstream tree-sitter folks.
@casouri Sorry for discussing here -- hope it's not an issue. I wonder if there are better places for these kinds of discussions...I suppose if people are not adverse, there are the matrix and discord options (they are bridged) listed here.