nvim-treesitter
Exact queries
This restructures the query definitions, and breaks some stuff. I'm open to changes.
- Queries are now grouped by language, and match exact node types.
- Queries are categorized, and those categories can be used to enable/disable groups of queries.
- A list of
lastandskipnodes are defined directly inside the query itself. -
fallback_patternscan be used to mostly replicate the old behavior, which enables the user to add some missing pieces in a simpler way than adding query definition for an entire language. -
exclude_patternswork the same as before.
If this was to be merged, we would definitely have to communicate the breaking changes to the user. I think versioning this plugin would be a start, and validating the user configuration could also save some people a lot of time and frustration.
I know this is a very big change (it got a bit out of control), don't feel forced to do anything. I just wanted to dump this somewhere for now.
It's an interesting change. Can you explain the benefits and the issues that are solved by this? Also I think if we merge this we should split language configurations into a separate file.
I started out specifying exact queries for languages using the existing structure, to eliminate false positives and have multi-line support for more node types. That way the parts essentially belonging together, like the context node type, the last node type or field name and nodes that should be skipped, are scattered all over the place. That made adding more languages a bit of a pain. So the new structure essentially groups together all parts that are relevant to one context node into one lua table.
Realizing that now the user can't easily enable/disable types of nodes across languages like if statements or for loops, I came up with categories, that are language agnostic, and allow the user to do just that, even a little more precise. For singular context nodes there are still exclude patterns.
When queries for a language are specified, no other patterns are checked (to not find false positives). So to not completely break all user configuration, there are still the fallback patterns for simplicity to quickly add support for new languages without having to search for each exact node type.
It's a good change in theory, but I'm worried that in practice it introduces more complexity without fixing actual open issues. We've been worried about false positives, however I don't see open bug reports of false positives and I haven't seen any while using the plugin, so I'm thinking maybe they're not a problem? The multi-line support for more nodes is nice though.
My opinion is very changeable though. @lewis6991 if you have an opinon here I'd be happy to hear as well.
