* bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior
2022-12-06 6:21 bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior Brian Leung
@ 2022-12-06 8:31 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-06 8:41 ` Brian Leung
2022-12-07 19:34 ` Yuan Fu
` (4 subsequent siblings)
5 siblings, 1 reply; 13+ messages in thread
From: Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-12-06 8:31 UTC (permalink / raw)
To: Brian Leung; +Cc: 59853
Hi Brian and thanks for the report!
Brian Leung <leungbk@posteo.net> writes:
> Given the following Java file:
>
> public abstract class Class {
> public static interface Interface {
> void someMethod();
>
> void [o]therMethod();
> }
> }
>
> If point is at the "o" in otherMethod, pressing C-M-a in java-ts-mode
> moves point to the beginning of that line. However, in java-mode, point
> moves to the beginning of Interface's declaration.
>
I see. To me this looks like java-ts-mode is "correct", in that the
next step "outwards" is to the method start itself. The point is in
fact inside the method still, IIUC.
> In the following Python file:
>
> def outer():
> def inner(i):
> return i
>
> [r]eturn 42
>
> If point is at the "r" in the outer return statement, pressing C-M-a in
> python-ts-mode moves point to the beginning of the line where the
> function "inner" is declared. However, in python-mode, point moves to
> the beginning of the line where "outer" is declared.
>
In this case I think python-mode is correct, becase the 'inner' function
is a sibling to the return statement, and it would make sense to go
directly to outer.
> This discrepancy in behavior makes it harder to use narrow-to-defun effectively.
>
Yeah, I understand. Do you agree on my points above? I just want to
make the problem clear to me :-)
Theo
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior
2022-12-06 8:31 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-12-06 8:41 ` Brian Leung
2022-12-06 10:36 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 13+ messages in thread
From: Brian Leung @ 2022-12-06 8:41 UTC (permalink / raw)
To: Theodor Thornhill; +Cc: 59853
Thanks for your response!
Theodor Thornhill <theo@thornhill.no> writes:
>> public abstract class Class {
>> public static interface Interface {
>> void someMethod();
>>
>> void [o]therMethod();
>> }
>> }
>>
>> If point is at the "o" in otherMethod, pressing C-M-a in
>> java-ts-mode
>> moves point to the beginning of that line. However, in
>> java-mode, point
>> moves to the beginning of Interface's declaration.
>>
>
> I see. To me this looks like java-ts-mode is "correct", in that
> the
> next step "outwards" is to the method start itself. The point
> is in
> fact inside the method still, IIUC.
I don't actually know Java, so my expectations/intuition for what
is "right" may be off. But from what I've read about, interfaces
should be used to group methods with empty bodies. Body-less forms
don't particularly feel like defuns to me, which is why I bring
this up. Additionally, interactively using narrow-to-defun in
java-ts-mode when point is inside the interface body produces
unusual results:
> public abstract class Class {
> public static interface Interface {
> void someMethod();
> * *
> void otherMethod();
> *}*
> }
If you narrow-to-defun with point inside the interface body and
not touching either brace (such as between the two methods), you
won't be able to capture the entire interface, and instead get
just a single-line method. Meanwhile, if point touches the right
brace, then narrow-to-defun yields
> void otherMethod();
> }
> }
when capturing the entire interface might make more sense.
>> def outer():
>> def inner(i):
>> return i
>>
>> [r]eturn 42
>>
>> If point is at the "r" in the outer return statement, pressing
>> C-M-a in
>> python-ts-mode moves point to the beginning of the line where
>> the
>> function "inner" is declared. However, in python-mode, point
>> moves to
>> the beginning of the line where "outer" is declared.
>>
>
> In this case I think python-mode is correct, becase the 'inner'
> function
> is a sibling to the return statement, and it would make sense to
> go
> directly to outer.
Yeah, I agree here.
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior
2022-12-06 8:41 ` Brian Leung
@ 2022-12-06 10:36 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-07 9:51 ` Brian Leung
0 siblings, 1 reply; 13+ messages in thread
From: Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-12-06 10:36 UTC (permalink / raw)
To: Brian Leung; +Cc: casouri, 59853
Brian Leung <leungbk@posteo.net> writes:
> Thanks for your response!
>
> Theodor Thornhill <theo@thornhill.no> writes:
>
>>> public abstract class Class {
>>> public static interface Interface {
>>> void someMethod();
>>>
>>> void [o]therMethod();
>>> }
>>> }
>>>
>>> If point is at the "o" in otherMethod, pressing C-M-a in
>>> java-ts-mode
>>> moves point to the beginning of that line. However, in
>>> java-mode, point
>>> moves to the beginning of Interface's declaration.
>>>
>>
>> I see. To me this looks like java-ts-mode is "correct", in that
>> the
>> next step "outwards" is to the method start itself. The point
>> is in
>> fact inside the method still, IIUC.
>
> I don't actually know Java, so my expectations/intuition for what
> is "right" may be off. But from what I've read about, interfaces
> should be used to group methods with empty bodies. Body-less forms
> don't particularly feel like defuns to me, which is why I bring
> this up. Additionally, interactively using narrow-to-defun in
> java-ts-mode when point is inside the interface body produces
> unusual results:
>
>> public abstract class Class {
>> public static interface Interface {
>> void someMethod();
>> * *
>> void otherMethod();
>> *}*
>> }
Not sure I can reproduce this. I made two files:
```
package Foo;
import some.thing;
interface Foo {
void foo();
}
````
```
package Foo;
import some.thing;
public abstract class Fooo {
public static interface Foo {
void foo();
}
}
```
In the first one, when point is on the 'f' of 'foo()' I get narrowed to
that line. If I'm at column 0 of the same line, I see the whole
interface, but not the package declaration or import statement. That
seems correct to me. Also I see similar results on the other file.
What am I missing?
>>> def outer():
>>> def inner(i):
>>> return i
>>>
>>> [r]eturn 42
>>>
>>> If point is at the "r" in the outer return statement, pressing
>>> C-M-a in
>>> python-ts-mode moves point to the beginning of the line where
>>> the
>>> function "inner" is declared. However, in python-mode, point
>>> moves to
>>> the beginning of the line where "outer" is declared.
>>>
>>
>> In this case I think python-mode is correct, becase the 'inner'
>> function
>> is a sibling to the return statement, and it would make sense to
>> go
>> directly to outer.
>
> Yeah, I agree here.
Great! This sounds like a different bug report though.
Theo
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior
2022-12-06 10:36 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-12-07 9:51 ` Brian Leung
2022-12-07 11:33 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 13+ messages in thread
From: Brian Leung @ 2022-12-07 9:51 UTC (permalink / raw)
To: Theodor Thornhill; +Cc: casouri, 59853
Theodor Thornhill <theo@thornhill.no> writes:
> Not sure I can reproduce this.
Sorry, I made a mistake in my description. I additionally noticed
additional odd results in java-ts-mode. Let me try again:
> p[u]blic abstract class Class {
> public static interface Interface {
> void someMethod();
> [*]
> void otherMethod();
> [}]
> }
1. When point is at the "u" in "public", narrow-to-defun cuts off
"pu" and moves point to "b".
2. When point is anywhere in the first line of the class
declaration, mark-defun highlights "void otherMethod()", instead
of the entire class declaration.
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 [*].
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.
4. When point is on the closing bracket of the interface
definition, narrow-to-defun captures
> void otherMethod();
> }
> }
which looks quite unusual to me.
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior
2022-12-07 9:51 ` Brian Leung
@ 2022-12-07 11:33 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-09 3:35 ` Brian Leung
0 siblings, 1 reply; 13+ messages in thread
From: Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-12-07 11:33 UTC (permalink / raw)
To: Brian Leung; +Cc: casouri, 59853
[-- Attachment #1: Type: text/plain, Size: 1978 bytes --]
Brian Leung <leungbk@posteo.net> writes:
> Theodor Thornhill <theo@thornhill.no> writes:
>
>> Not sure I can reproduce this.
>
> Sorry, I made a mistake in my description. I additionally noticed
> additional odd results in java-ts-mode. Let me try again:
>
>> p[u]blic abstract class Class {
>> public static interface Interface {
>> void someMethod();
>> [*]
>> void otherMethod();
>> [}]
>> }
Right - thanks! Now I understand what you describe. I'll try to answer
them case by case.
>
> 1. When point is at the "u" in "public", narrow-to-defun cuts off
> "pu" and moves point to "b".
Yes, this definitely looks like a bug. This is probably because the
whole 'public' keyword maps to the declaration, and we don't move to the
actual beginning. I can look into this.
> 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.
> 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.
> 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?
> 4. When point is on the closing bracket of the interface
> definition, narrow-to-defun captures
>
>> void otherMethod();
>> }
>> }
>
> which looks quite unusual to me.
Yes, I agree with this one. My guess is that this is the same as number
one.
What do you think?
Theo
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Make-more-granular-defun-type-regexp.patch --]
[-- Type: text/x-diff, Size: 1459 bytes --]
From ef79549e793773b50faea9bad2cd35509e5714e1 Mon Sep 17 00:00:00 2001
From: Theodor Thornhill <theo@thornhill.no>
Date: Wed, 7 Dec 2022 10:07:37 +0100
Subject: [PATCH] Make more granular defun-type-regexp
We don't want to match local_variable_declaration and others to hit on
beginning-of-defun. The fix is just to make the regexp a bit more
granular.
* lisp/progmodes/java-ts-mode.el (java-ts-mode): Use regexp-opt to
distinguish more granularly.
---
lisp/progmodes/java-ts-mode.el | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/lisp/progmodes/java-ts-mode.el b/lisp/progmodes/java-ts-mode.el
index 2c42505ac9..db2566d655 100644
--- a/lisp/progmodes/java-ts-mode.el
+++ b/lisp/progmodes/java-ts-mode.el
@@ -317,7 +317,15 @@ java-ts-mode
(append "{}():;," electric-indent-chars))
;; Navigation.
- (setq-local treesit-defun-type-regexp "declaration")
+ (setq-local treesit-defun-type-regexp
+ (regexp-opt '("method_declaration"
+ "class_declaration"
+ "record_declaration"
+ "interface_declaration"
+ "enum_declaration"
+ "import_declaration"
+ "package_declaration"
+ "module_declaration")))
;; Font-lock.
(setq-local treesit-font-lock-settings java-ts-mode--font-lock-settings)
--
2.34.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior
2022-12-07 11:33 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-12-09 3:35 ` Brian Leung
2022-12-09 15:59 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 13+ messages in thread
From: Brian Leung @ 2022-12-09 3:35 UTC (permalink / raw)
To: Theodor Thornhill; +Cc: casouri, 59853
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?
>> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior
2022-12-09 3:35 ` Brian Leung
@ 2022-12-09 15:59 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 13+ messages in thread
From: Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-12-09 15:59 UTC (permalink / raw)
To: Brian Leung; +Cc: casouri, 59853
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?
>
I understand. I think that either we need to tweak the
treesit-defun-type-regexp or make use of something like:
(treesit-node-on (point) (point)) in the code that searches for
beginning/end-of-defun.
That code should return what you want, right?
>>> 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.
Yeah. But I believe Yuan is cooking on some code wrt
beginning/end-of-defun, so maybe we should just wait and see what he
comes up with.
Theo
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior
2022-12-06 6:21 bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior Brian Leung
2022-12-06 8:31 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-12-07 19:34 ` Yuan Fu
2022-12-21 5:24 ` Yuan Fu
` (3 subsequent siblings)
5 siblings, 0 replies; 13+ messages in thread
From: Yuan Fu @ 2022-12-07 19:34 UTC (permalink / raw)
To: Theodor Thornhill; +Cc: Brian Leung, 59853
Theodor Thornhill <theo@thornhill.no> writes:
> Brian Leung <leungbk@posteo.net> writes:
>
>> Theodor Thornhill <theo@thornhill.no> writes:
>>
>>> Not sure I can reproduce this.
>>
>> Sorry, I made a mistake in my description. I additionally noticed
>> additional odd results in java-ts-mode. Let me try again:
>>
>>> p[u]blic abstract class Class {
>>> public static interface Interface {
>>> void someMethod();
>>> [*]
>>> void otherMethod();
>>> [}]
>>> }
>
> Right - thanks! Now I understand what you describe. I'll try to answer
> them case by case.
>
>>
>> 1. When point is at the "u" in "public", narrow-to-defun cuts off
>> "pu" and moves point to "b".
>
> Yes, this definitely looks like a bug. This is probably because the
> whole 'public' keyword maps to the declaration, and we don't move to the
> actual beginning. I can look into this.
>
>> 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.
>
>> 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.
>
>> 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?
>
>> 4. When point is on the closing bracket of the interface
>> definition, narrow-to-defun captures
>>
>>> void otherMethod();
>>> }
>>> }
>>
>> which looks quite unusual to me.
>
> Yes, I agree with this one. My guess is that this is the same as number
> one.
>
> What do you think?
>
> Theo
There’s a discussion semi-related to this on emacs-devel, where Alan
mentioned this:
In CC Mode, it has been configurable via the user option c-defun-tactic
for somewhere between ten and fifteen years. When c-defun-tactic is t,
C-M-a/e go to the start/end of the top level defuns. When it is the
symbol go-outward, C-M-a/e move to the next start/end of defun, if any,
at the current level of class/namespace nesting, and move outwards to
the next level of class/namespace nesting when a class/namespace boundary
is reached.
If we add this option to tree-sitter, user could decide what bahavior
they want. I’m planning to work on that. Though there is already
something that can more-or-less do this: treesit-defun-prefer-top-level.
Yuan
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior
2022-12-06 6:21 bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior Brian Leung
2022-12-06 8:31 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-07 19:34 ` Yuan Fu
@ 2022-12-21 5:24 ` Yuan Fu
2022-12-21 5:28 ` Yuan Fu
` (2 subsequent siblings)
5 siblings, 0 replies; 13+ messages in thread
From: Yuan Fu @ 2022-12-21 5:24 UTC (permalink / raw)
To: Theodor Thornhill; +Cc: leungbk, 59853
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?
>>
>
> I understand. I think that either we need to tweak the
> treesit-defun-type-regexp or make use of something like:
>
> (treesit-node-on (point) (point)) in the code that searches for
> beginning/end-of-defun.
>
> That code should return what you want, right?
>
>>>> 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.
>
> Yeah. But I believe Yuan is cooking on some code wrt
> beginning/end-of-defun, so maybe we should just wait and see what he
> comes up with.
I’ve cooked and served said code. Now beginning/end-of-defun should work
reliably, and you can configure its behavior with treesit-defun-tactic.
I also fixed c-ts-mode-indent-defun with the new defun functions.
Yuan
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior
2022-12-06 6:21 bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior Brian Leung
` (2 preceding siblings ...)
2022-12-21 5:24 ` Yuan Fu
@ 2022-12-21 5:28 ` Yuan Fu
2022-12-22 8:59 ` Yuan Fu
2023-01-07 23:12 ` Yuan Fu
5 siblings, 0 replies; 13+ messages in thread
From: Yuan Fu @ 2022-12-21 5:28 UTC (permalink / raw)
To: Theodor Thornhill; +Cc: leungbk, 59853
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?
>>
>
> I understand. I think that either we need to tweak the
> treesit-defun-type-regexp or make use of something like:
>
> (treesit-node-on (point) (point)) in the code that searches for
> beginning/end-of-defun.
>
> That code should return what you want, right?
>
>>>> 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.
>
> Yeah. But I believe Yuan is cooking on some code wrt
> beginning/end-of-defun, so maybe we should just wait and see what he
> comes up with.
Oh wait, this report is about narrow-to-defun rather than
c-ts-mode-indent-defun, err that’s not fixed yet, because
beginning/end-of-defun doens’t use tree-sitter anymore (headache). I’ll
try to address this soon.
Yuan
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior
2022-12-06 6:21 bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior Brian Leung
` (3 preceding siblings ...)
2022-12-21 5:28 ` Yuan Fu
@ 2022-12-22 8:59 ` Yuan Fu
2023-01-07 23:12 ` Yuan Fu
5 siblings, 0 replies; 13+ messages in thread
From: Yuan Fu @ 2022-12-22 8:59 UTC (permalink / raw)
To: Theodor Thornhill; +Cc: leungbk, 59853
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
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior
2022-12-06 6:21 bug#59853: 30.0.50; tree-sitter modes have unexpected beginning-of-defun behavior Brian Leung
` (4 preceding siblings ...)
2022-12-22 8:59 ` Yuan Fu
@ 2023-01-07 23:12 ` Yuan Fu
5 siblings, 0 replies; 13+ messages in thread
From: Yuan Fu @ 2023-01-07 23:12 UTC (permalink / raw)
To: Theodor Thornhill; +Cc: leungbk, 59853
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
^ permalink raw reply [flat|nested] 13+ messages in thread