Re: Tree-sitter integration on feature/tree-sitter

[Yoav Marco]

Cool that you're chipping in, we need feedback from the community and
specifically package writers.

Abin Simon <abinsimon10@gmail.com> writes:

> Yoav Marco <yoavm448@gmail.com> writes:
>
>> I could try to make a self-updating repo or something with CI -
>> https://github.com/meain/evil-textobj-tree-sitter for example pulls
>> highlights.scm changes from nvim's repo weeky.
>
> Just wanted to give a heads up that neovim has non standard items in
> their queries. For example you will find things like `vim-match` and
> `lua-match` in the queries.

I guess we could support a "lisp-match" predicate, that would run a
function and match if it returns non-nil. Or just try and look up
non-existing predicates as Lisp functions. Would that be useful?

> https://github.com/nvim-treesitter/nvim-treesitter/blob/989c75046c46d2ed96bb65c5badd6b8f785e7f09/queries/go/highlights.scm#L19
>
>
> I ran into similar issues in the meain/evil-textobj-tree-sitter and had
> to write scritps to convert them to something that works in emacs.
>
> ref: https://github.com/meain/evil-textobj-tree-sitter/issues/33

Okay, so the problem here is that neovim supports making up arbitrary
captures as a range over other captures: (#make-range! "c" @a @b) means
"make a new capture @c that spans from @a to @b". It helps when you e.g
want to make a capture spanning only two children of a node and not the
other children.

The problem is, making up new captures in Lisp isn't trivial, it would
need special support form the C side.

Could we support this?

1. We could allow a special case where if Lisp predicate return a list
   (name beg end) that would have the same effect as "make new capture
   @c with range @a, @b".

2. But captures are returned from treesit-query-capture as pairs of
   (capture-name . node), and we can't just make up a node with
   arbitrary range.

3. We could report non-boolean capture results by just appending that
   result to the list of pairs, but that just adds complexity to users
   of treesit-query-capture. And it doesn't support the simpler use case
   of 1, where it's just reported as a normal capture.

Yuan, any thoughts on capture extensibility?

  Yoav