Re: Plug treesit.el into other emacs constructs

[Theodor Thornhill <theo@thornhill.no>]

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

>> Great.  It seems there has been almost no development, nor documentation
>> done in this area for a long time.  Should I try to improve on this part
>> of the code while I'm at it?
>
> That would be welcome, yes.
>

Ok, will do.

>> Yeah, that's what I'm thinking too.  I'm just thinking we should be
>> clear on what a word/sexp/sentence/paragraph/defun etc is in non-lisp
>> and non-human languages.
>
> In the context of SMIE I came up with a usable meaning for sexp (which
> I've been trying to explain in this thread), but for sentence and
> paragraph it seems harder and is likely to depend on the specifics of
> the language (e.g. for some languages "sentence" might be mapped to
> "instruction" or maybe "instruction that doesn't itself contain nested
> instructions", but some languages don't have a notion of instruction).
>

Yeah, I understand.

>>>> Now I'm having issues where movement over sexps ends up not in the
>>>> same place.
>>> Same place as?
>> IIRC there's no guarantee that the movement sequence used for
>> transpose-sexp moves over the same blocks of code, so in non-lisp
>> languages there's no real semantic to go from.
>
> I guess in general it can be difficult to be consistent, indeed.
> In SMIE I preserve the following (or at least I try to):
>
>     <FOO> infix <BAR>
>     ^   ^       ^   ^
>     AB  AE      BB  BE
>
> if `transpose-sexp` swaps FOO and BAR, then `forward-sexp` from AE goes
> to BE and `backward-sexp` from BB goes to AB.  But when you start to
> consider mixfix syntax it can become much less clear what needs to
> be done.  I don't think we should worry too much if `transpose-sexp` and
> `forward/backward-sexp` don't align 100% is all cases: we should strive
> to keep them consistent, but it's OK to break down in corner cases.
>

Actually, I think there is a nice solution waiting for us.  If we
consider the 'balanced expressions' to be swapped in transpose-sexps as
siblings, we could just:

(defun treesit-transpose-sexps (&optional arg)
  "Tree-sitter `beginning-of-defun' function.
ARG is the same as in `beginning-of-defun'."
  (interactive "*p")
  (if-let* ((node (treesit-node-at (point)))
            (prev (treesit-node-prev-sibling node))
            (next (treesit-node-next-sibling node)))
      (list (cons (treesit-node-start prev)
                  (treesit-node-end prev))
            (cons (treesit-node-start next)
                  (treesit-node-end next)))
    ;; Hack to trigger the error message in transpose-subr-1 when we
    ;; don't have siblings to swap.
    (list (cons 0 1) (cons 0 1))))

If this code is plugged into transpose-sexps we get this nice behavior:

Python:

```
def foo():
    return x |if x == 5 else False

def foo():
    return x == 5 if x| else False
```

and

```
def foo():
    return x if x == 5 el|se False

def foo():
    return x if False else x == 5|
```

and

```
def foo():
    return| x if x == 5 else False ;; Don't have two things to transpose
```

Java:

```
public class foo {
    void foo(String x,| int y) {}
}

public class foo {
    void foo(int y, String x|) {}
```

and

```
public class foo {
    void foo() {
        if (x =|= y) {}
    }
}

public class foo {
    void foo() {
        if (y == x|) {}
    }
}
```

and

```
public class foo {
    void foo(String x, int y) {
        foo(a + 4|, c * b + y, b, d).bar();
    }
}

public class foo {
    void foo(String x, int y) {
        foo(c * b + y, a + 4|, b, d).bar();
    }
}
```

and 

```
foo(a + 4, c * b |+ y, b, d);

foo(a + 4, y + c * b, b, d);
```


Now forward/backward-sexp can actually work a little differently, as you
suggest, or we can let it use the same "move over siblings"-semantic.
In that case we don't even need the treesit-sexp-type-regexp variables to
control this, I think.

What do you think?

Theo