Re: Plug treesit.el into other emacs constructs

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> ** Forward-sexp:
>>> Executing C-M-f repeatedly will go from:
>>> ```
>>> public void foo(|String bar, String baz) {}
>>> ```
>>> to
>>> ```
>>> public void foo(String bar|, String baz) {}
>>> ```
>>
>> That looks wrong.  `String` is a valid AST node.  Whether it gets a node
>> in tree-sitter or not, I don't know, but here there are several "sexps"
>> that start at point and I think `forward-sexp` should be conservative
>> and keep advancing by the smallest option.
> I understand.  My reasoning is that 'forward-word' is suitable for that,

It's not, tho, because it stops within identifiers like "foo_bar".
There's a similar question for things like `String.match`.

> and to actually gain something from these we need to use a little bigger
> constructs.  In tree-sitter 'String' isn't really valid, because you
> need the identifier to create a complete node.

I think we should not define the "ideal" behavior based on what
Tree-sitter provides.
As I said, in the *A*ST, `String` is a valid node.
It's especially true if you consider more complex types like

    public void foo(Array<Foo<List<Int>, String>> bar, String baz)

> In this case I'd think that forward-sexp would do:
> ```
> x = |f (x) * 3 + 2;
> x = f (x)| * 3 + 2;
> x = f (x) * 3| + 2;
> x = f (x) * 3 + 2;|
> ```
> Or something like that.

Similarly here I think it should first stop after `f`.
The other ones look right to me.

> So that multiple transpose-sexps would move
> 'f(x)' over the operators, swapping with the integers.

You could still do that, but you'd have to start with point next to `*`
to specify the node whose children you want to swap.

>>> ```
>>> public void foo(String bar, String baz|) {}
>>> ```
>>
>> That one's right :-)
>
> Why is this one right, and the above not?

Because point was left of the comma and the smallest right child of the
corresponding node is "String bar" and not "String" (which is more like
the left child of the node that covers "String bar").

> Thanks for the feedback so far.  I interpret this that this feature is
> wanted, so I'll make a more serious effort and get back to you.

Yes, definitely.  It's one of the best features of SMIE compared to
"hand-written" indentation code, if you ask me :-)
Tree-sitter should be able to do it even better.

> BTW, where are the semantics for these movement functions defined?

In our heads.

> I mean, what construct is each one expected to jump over?

In my book "sexp" movement should jump over subtrees of the AST.


        Stefan