emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Plug treesit.el into other emacs constructs


From: Theodor Thornhill
Subject: Re: Plug treesit.el into other emacs constructs
Date: Tue, 13 Dec 2022 21:02:15 +0100

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

>>>> ** 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`.
>

Ok, I think I understand.  But 'void foo(String bar)' is not the same as
'String.format', where 'void foo(bar String)' would make to sense, but
'format.String' could.

>> 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)
>

And in this case multiple forward-sexps would be

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

and transpose-sexp would be:

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

Not really sure how to accomodate the two behaviors in the same
function, but I'll get there.

>> 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.
>

Ok

>> 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.
>

Yeah.

>>>> ```
>>>> 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").
>

Ok, so you mean that forward-sexp should incrementally cover more and
more of a node, but transpose-sexp would find the _whole_ node, then
swap it with the one "in front" of it?

so in 'void(String foo, int bar)'

forward-sexp would go word by word, but transpose-sexp would capture
"String foo" and "int bar" when point is on the comma?

>> 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.
>

Nice!

>> BTW, where are the semantics for these movement functions defined?
>
> In our heads.
>

Sweet - I might bother you more, then.

>> I mean, what construct is each one expected to jump over?
>
> In my book "sexp" movement should jump over subtrees of the AST.

So given this ast point should move over each named node, no matter if
transposing them would create broken code?

```
(class_declaration
 (modifiers public)
 class name: (identifier)
 body: 
  (class_body {
   (method_declaration
    dimensions: 
     (generic_type (type_identifier)
      (type_arguments <
       (generic_type (type_identifier)
        (type_arguments < (type_identifier) >))
       >))
    body: (identifier)
    (formal_parameters (
     (formal_parameter type: (type_identifier) dimensions: (identifier))
     ,
     (formal_parameter type: (type_identifier) dimensions: (identifier))
     ))
    (block { }))
   }))
```

Forgive my stupid questions, I just want it to be clear to me what I'm
doing here ;)

Theo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]