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

[Yuan Fu]

Yuan Fu <casouri@gmail.com> writes:

> Yuan Fu <casouri@gmail.com> writes:
>
>> Theodor Thornhill <theo@thornhill.no> writes:
>>
>>> Brian Leung <leungbk@posteo.net> writes:
>>>
>>>> Theodor Thornhill <theo@thornhill.no> 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?
>>>>
>>>
>>> I believe it was the one I included as a patch here.
>>>
>>>>>> 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?
>
> That’s hard to do with the current narrow-to-defun, we can add a
> new version that is aware of nested defuns and remap narrow-to-defun to
> it in tree-sitter modes. In the future we can improve stock
> narrow-to-defun to support nested defuns.
>
> Yuan

Defun navigatio is largely fixed now, so I’m closing this. For
narrow-to-defun to completely work we need to improve
beginning/end-of-defun to support nested defuns.

Yuan