Subject: bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior

From: Brian Leung <[email-masked]>
Date: Fri, 09 Dec 2022 03:35:21 +0000

Theodor Thornhill <[email-masked]> writes:

>> 2. When point is anywhere in the first line of the class 
>> declaration, mark-defun highlights "void otherMethod()", 
>> instead 
>> of the entire class declaration.
>
> Yeah, I think I've fixed this in a patch I just submitted.

Which commit are you referring to?

>> 3a. When point is at the [*] in between someMethod and 
>> otherMethod, narrow-to-defun captures "void otherMethod()". I 
>> feel 
>> that since the methods inside the interface declaration have no 
>> bodies, it makes more sense to capture the entire interface 
>> definition if point is at [*].
>
> Maybe, but I don't believe this is wrong either.

Let me rephrase my request. Consider the following example:

> class Cow implements Animal {
>   public void animalSound() {
>     // The body of animalSound() is provided here
>     System.out.println("The cow says: moo");
>   }
>
> [*]
>
>   public void sleep() {
>     // The body of sleep() is provided here
>     System.out.println("Zzz");
>   }
> }

Both the methods have bodies. If point is at the [*], I would like 
for narrow-to-defun to capture the entire class declaration, since 
point is not really contained in either method. (For this 
particular example, java-mode presently agrees with java-ts-mode.)

Is there a clean way of ensuring that, when point lies between 
(and is not contained in) those two methods, point is not treated 
as if it were in one of those methods' tree-sitter nodes?

>> 3b. Arguably, even if point were on the method declarations, we 
>> might still want to (as plain java-mode does) capture the 
>> entire 
>> interface definition, since body-less method declarations don't 
>> feel especially defun-like.
>
> Maybe.  Can you try applying the below patch and see if this 
> changes
> anything for you?

It captures the entire interface definition only when I remove 
"method_declaration" (which we probably want to keep) from the 
regexp.