Re: Plug treesit.el into other emacs constructs

[Theodor Thornhill <theo@thornhill.no>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>In this case, yes.  But in other cases it will move at different levels
>>>of the tree.  E.g.:
>>>
>>>   int x = f (b + 4, c * 7 - z * 2, d, e);
>>>
>>>It will sometimes move over the whole instruction, and other times over
>>>just a single variable or over a whole argument or over just a "factor".
>>>This depends on where point is when `forward/backward-sexp` is called.
>>
>> Yeah. I think this example shows what I find unintuitive. If point is right
>> before the first comma, and we transpose-sexps, it could end up swapping
>> 4 for c * 7 - z * 2, which would rarely make sense in this context.
>
> If so, that would be a bug in `transpose-sexp`, agreed.
> I'm talking here about `forward/backward-sexp`.
> The two are linked, but we shouldn't use one to justify a bug in the other.

Sure, but I think they necessarily needs to be viewed as a whole.  If we
drop tree-sitter or SMIE (which I actually know pretty well) for one
moment, the cc-mode based java-mode would exhibit the exact behavior I
described.  If it's a bug in tranpsose-sexps it is definitely an issue
with forward/backward-sexp, because in every situation the positions to
be swapped is just "backward-sexp - forward-sexp - forward-sexp -
backward-sexp", right? And the thing in the middle, usually a comma,
operators or other is the space between that doesn't move.  I also
observe this fixme inside of transpose-words:

  ;; FIXME: `foo a!nd bar' should transpose into `bar and foo'.

I read this more like it's how transpose-sexps should behave on text.
There are almost no differences between forward-word and forward-sexp in
normal prose, bar the case of delimiters, IIUC.  Wouldn't it make sense
to make transpose-sexps actually do what that fixme asks?

And why is the

		 (cons (progn (funcall mover x) (point))
		       (progn (funcall mover (- x)) (point)))

in this form, and not some pseudo-code like:
(cons '(backward-thing-from-start-point forward-thing-point)
      '(forward-thing-from-start-point backward-thing-point))


So that 'foo a|nd bar' would create these points:

|foo| a|nd |bar|
1   2  ^   4   3
       start


Then forward-word could behave like it does now.  Now I'm having issues
where movement over sexps ends up not in the same place.


>
> `Forward-sexp` from
>
>     int x = f (b + 4|, c * 7 - z * 2, d, e);
>
> should work by delimiting the two things to swap *plus* the thing
> in-between, and in this case it should be:
>
>     int x = f (<b + 4>, <c * 7 - z * 2>, d, e);
>
> Notice how it needs to figure out the ", ".  Once this is figured out,
> it's easy to use `forward/backward-sexp` to find the other 2 boundaries
> (if you want to re-use the `forward/backward-sexp`, like the code
> currently does):
>
> Use `forward-sexp` from
>
>     int x = f (b + 4|, c * 7 - z * 2, d, e);
>
> and `backward-sexp` from
>
>     int x = f (b + 4, |c * 7 - z * 2, d, e);
>
>> Swapping b + 4 with c * 7 - z * 2 would make sense here,  imo.
>> I believe this is not how you see it? 
>
> Looks like I wasn't clear enough.  I do agree with you on this, and SMIE
> agrees with you as well, if you try `M-C-t` on the above code in
> tuareg-mode.

I think we agree, yes.  Thanks for taking the time :-)

Theo