Re: Plug treesit.el into other emacs constructs

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

>>> I mean, what construct is each one expected to jump over?
>> In my book "sexp" movement should jump over subtrees of the AST.
> It’s pretty hard to judge which subtree to move over at a given point in an
> AST. For example, when point is at | in the following text:
>
> (|X.y(z), alpha)
>
> Should point move over X, or X.y, or X.y(z)? All three subtrees has their
> beg=(point).

Exactly.  It's even a bit worse: I'd also argue that an additional valid
choice is to move over the whole "X.y(z), alpha".

The semantics I opted for in SMIE is to choose the smallest/deepest
subtree.  That's what best matches the previous behavior of
`forward-sexp`.  If the users want to move over larger units they have
to place their point elsewhere (e.g. if it's just before ".", then
moving over "y" wouldn't make sense because "y" is attached to "y(z)"
and not to ".", only "y(z)" is attached to ".").

> Just a thought, but maybe we can let major modes define what’s an “abstract
> list”, and sexp-forward would move across the immediate children of abstract
> lists. Eg, abstract lists in C would contain block, argument list,
> statement, etc. And in the example above forward-sexp would move across
> X.y(z) because it’s an immediate children of the enclosing abstract list,
> the argument list.

Using the semantics I advocate, the user needs to place his point just
to the left of `;` in order for `forward-sexp` to jump over the next
instruction (or to the right of the `;` in order to jump over the
previous instruction with `backward-sexp`).


        Stefan