Cross-posted with #26563

I once also had a similar need, although not significantly as I settled down with a different approach & workaround. The problem is that very long text with many TS nodes may not be fully captured with a correct query.

An example -- I was trying to fold "luadocs", a maximally consecutive group of comment lines to workaround the current issue where (node)+ quantifiers do not work properly (#17060).

;; extends

; Fold consecutive luadoc comments
 (
  (_) @_non_comment (#not-has-type? @_non_comment comment)
  . (comment) @_start
  . (comment)*
  . (comment) @_end
  . [(function_declaration) (assignment_statement) (variable_declaration)]
  (#make-range! "fold" @_start @_end)
 )

On a example file $VIMRUNTIME/runtime/lua/vim/lsp.lua

(1) with ts_match_limit 256:

• Line 725-805 (~81 lines) are not captured as @fold because this is too long, probably because of treesitter injection of luadoc. See the signcolumn for evaluated foldexpr. All other luadoc comments that are relatively short can be correctly captured.

(2) with ts_match_limit 1024:

• Now Line 725-805 can be folded.

I know the above custom query implementation is kind of crazy hacky and not quite efficient, it'd be better to be addressed by improving the parser so that it can have an appropriate hierarchy and groupings of consecutive lines of comments. So I ended up with an alternative foldexpr implementation.

The downside is performance impact: it's slow. The ts_match_limit value of 1024 makes parsing noticeably slow; neovim will freeze for a few seconds while parsing the buffer (~2500 lines).

Is this tree-sitter-grammars/tree-sitter-yaml#9 perhaps related?

Probably not, because the bug you show is more like a parser fails to parse a very long document correctly. This issue is about query (which should work on a "valid" syntax tree upon successful parsing), so I don't think it's related.