GNU bug report logs -
#60751
30.0.50; Treesit indent rule with missing semi in java-ts-mode
Previous Next
Reported by: Theodor Thornhill <theo <at> thornhill.no>
Date: Thu, 12 Jan 2023 09:29:02 UTC
Severity: normal
Found in version 30.0.50
Fixed in version 29.1
Done: Yuan Fu <casouri <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 60751 in the body.
You can then email your comments to 60751 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
casouri <at> gmail.com, bug-gnu-emacs <at> gnu.org
:
bug#60751
; Package
emacs
.
(Thu, 12 Jan 2023 09:29:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Theodor Thornhill <theo <at> thornhill.no>
:
New bug report received and forwarded. Copy sent to
casouri <at> gmail.com, bug-gnu-emacs <at> gnu.org
.
(Thu, 12 Jan 2023 09:29:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi Yuan!
Consider this java code (point at |, and note the missing semi):
```
class foo {
public void foo() {
var x = foo
.foo()|
}
}
```
If I press RET now, indent ends up here:
```
class foo {
public void foo() {
var x = foo
.foo()
|
}
}
```
Matched rule is (which I'll change in a bit anyway):
```
((parent-is "block") (and parent parent-bol) java-ts-mode-indent-offset)
```
and the parse tree is:
```
(program
(class_declaration class name: (identifier)
body:
(class_body {
(method_declaration
(modifiers public)
dimensions: (void_type) body: (identifier)
(formal_parameters ( ))
(block {
(local_variable_declaration type: (type_identifier)
declarator:
(variable_declarator dimensions: (identifier) =
value:
(method_invocation object: (identifier) . name: (identifier)
arguments: (argument_list ( ))))
type: ;)
}))
})))
```
and when this is invoked at point:
```
(treesit-node-at (point)) ;; #<treesit-node "}" in 90-91>
(treesit-node-parent (treesit-node-at (point))) ;; #<treesit-node block in 35-91>
```
In a way I would expect it to match either variable_declarator or
local_variable_declaration. I know this behavior has changed a couple
of times the last year, wrt treesit-node-at and treesit-node-on, but
it's a little over my head how this calcutation is done.
In this case the syntax tree has no errors, but the code won't compile.
Do you have any suggestions for how to remedy this in java-ts-mode only,
or is this something to be considered for treesit.el? Or maybe even a
bug in tree-sitter-java?
I see the tree-sitter playground [0] returns:
```
program [0, 0] - [8, 0]
class_declaration [0, 0] - [6, 1]
name: identifier [0, 6] - [0, 9]
body: class_body [0, 10] - [6, 1]
method_declaration [1, 4] - [5, 6]
modifiers [1, 4] - [1, 10]
type: void_type [1, 11] - [1, 15]
name: identifier [1, 16] - [1, 19]
parameters: formal_parameters [1, 19] - [1, 21]
body: block [1, 22] - [5, 6]
local_variable_declaration [2, 8] - [3, 18]
type: type_identifier [2, 8] - [2, 11]
declarator: variable_declarator [2, 12] - [3, 18]
name: identifier [2, 12] - [2, 13]
value: method_invocation [2, 16] - [3, 18]
object: identifier [2, 16] - [2, 19]
name: identifier [3, 13] - [3, 16]
arguments: argument_list [3, 16] - [3, 18]
MISSING ; [3, 18] - [3, 18]
```
Which in turn could be something new not supported in the version I run?
Theo
[0]: https://tree-sitter.github.io/tree-sitter/playground
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60751
; Package
emacs
.
(Fri, 13 Jan 2023 09:33:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 60751 <at> debbugs.gnu.org (full text, mbox):
Theodor Thornhill <theo <at> thornhill.no> writes:
> Hi Yuan!
>
> Consider this java code (point at |, and note the missing semi):
> ```
> class foo {
> public void foo() {
> var x = foo
> .foo()|
> }
> }
> ```
> If I press RET now, indent ends up here:
> ```
> class foo {
> public void foo() {
> var x = foo
> .foo()
> |
> }
> }
> ```
>
> Matched rule is (which I'll change in a bit anyway):
>
> ```
> ((parent-is "block") (and parent parent-bol) java-ts-mode-indent-offset)
> ```
>
>
> and the parse tree is:
>
> ```
> (program
> (class_declaration class name: (identifier)
> body:
> (class_body {
> (method_declaration
> (modifiers public)
> dimensions: (void_type) body: (identifier)
> (formal_parameters ( ))
> (block {
> (local_variable_declaration type: (type_identifier)
> declarator:
> (variable_declarator dimensions: (identifier) =
> value:
> (method_invocation object: (identifier) . name: (identifier)
> arguments: (argument_list ( ))))
> type: ;)
> }))
> })))
> ```
>
>
> and when this is invoked at point:
>
> ```
> (treesit-node-at (point)) ;; #<treesit-node "}" in 90-91>
> (treesit-node-parent (treesit-node-at (point))) ;; #<treesit-node block in 35-91>
> ```
>
> In a way I would expect it to match either variable_declarator or
> local_variable_declaration. I know this behavior has changed a couple
> of times the last year, wrt treesit-node-at and treesit-node-on, but
> it's a little over my head how this calcutation is done.
So when treesit-indent runs, it tries to get the largest node that
starts at BOL, where BOL is the first non-whitespace character of the
current line. In this case, there is no such node (because point is on
an empty line), so NODE is set to nil, and parent is set to the smallest
node that covers BOL, which is the (block) node.
> In this case the syntax tree has no errors, but the code won't compile.
> Do you have any suggestions for how to remedy this in java-ts-mode only,
> or is this something to be considered for treesit.el? Or maybe even a
> bug in tree-sitter-java?
Compile? You mean byte-compiling java-ts-mode.el? What do you want to
accomplish? The indentation you showed looks alright to me.
> I see the tree-sitter playground [0] returns:
> ```
>
>
> program [0, 0] - [8, 0]
> class_declaration [0, 0] - [6, 1]
> name: identifier [0, 6] - [0, 9]
> body: class_body [0, 10] - [6, 1]
> method_declaration [1, 4] - [5, 6]
> modifiers [1, 4] - [1, 10]
> type: void_type [1, 11] - [1, 15]
> name: identifier [1, 16] - [1, 19]
> parameters: formal_parameters [1, 19] - [1, 21]
> body: block [1, 22] - [5, 6]
> local_variable_declaration [2, 8] - [3, 18]
> type: type_identifier [2, 8] - [2, 11]
> declarator: variable_declarator [2, 12] - [3, 18]
> name: identifier [2, 12] - [2, 13]
> value: method_invocation [2, 16] - [3, 18]
> object: identifier [2, 16] - [2, 19]
> name: identifier [3, 13] - [3, 16]
> arguments: argument_list [3, 16] - [3, 18]
> MISSING ; [3, 18] - [3, 18]
> ```
>
> Which in turn could be something new not supported in the version I run?
The explorer probably did something wrong and added the "type:"
field name to the ";" node. Other than that I think the two parse tree
should agree with each other.
Yuan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60751
; Package
emacs
.
(Fri, 13 Jan 2023 10:32:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 60751 <at> debbugs.gnu.org (full text, mbox):
Yuan Fu <casouri <at> gmail.com> writes:
> Theodor Thornhill <theo <at> thornhill.no> writes:
>
>> Hi Yuan!
>>
>> Consider this java code (point at |, and note the missing semi):
>> ```
>> class foo {
>> public void foo() {
>> var x = foo
>> .foo()|
>> }
>> }
>> ```
>> If I press RET now, indent ends up here:
>> ```
>> class foo {
>> public void foo() {
>> var x = foo
>> .foo()
>> |
>> }
>> }
>> ```
>>
>> Matched rule is (which I'll change in a bit anyway):
>>
>> ```
>> ((parent-is "block") (and parent parent-bol) java-ts-mode-indent-offset)
>> ```
>>
>>
>> and the parse tree is:
>>
>> ```
>> (program
>> (class_declaration class name: (identifier)
>> body:
>> (class_body {
>> (method_declaration
>> (modifiers public)
>> dimensions: (void_type) body: (identifier)
>> (formal_parameters ( ))
>> (block {
>> (local_variable_declaration type: (type_identifier)
>> declarator:
>> (variable_declarator dimensions: (identifier) =
>> value:
>> (method_invocation object: (identifier) . name: (identifier)
>> arguments: (argument_list ( ))))
>> type: ;)
>> }))
>> })))
>> ```
>>
>>
>> and when this is invoked at point:
>>
>> ```
>> (treesit-node-at (point)) ;; #<treesit-node "}" in 90-91>
>> (treesit-node-parent (treesit-node-at (point))) ;; #<treesit-node block in 35-91>
>> ```
>>
>> In a way I would expect it to match either variable_declarator or
>> local_variable_declaration. I know this behavior has changed a couple
>> of times the last year, wrt treesit-node-at and treesit-node-on, but
>> it's a little over my head how this calcutation is done.
>
> So when treesit-indent runs, it tries to get the largest node that
> starts at BOL, where BOL is the first non-whitespace character of the
> current line. In this case, there is no such node (because point is on
> an empty line), so NODE is set to nil, and parent is set to the smallest
> node that covers BOL, which is the (block) node.
>
Right, thanks!
>> In this case the syntax tree has no errors, but the code won't compile.
>> Do you have any suggestions for how to remedy this in java-ts-mode only,
>> or is this something to be considered for treesit.el? Or maybe even a
>> bug in tree-sitter-java?
>
> Compile? You mean byte-compiling java-ts-mode.el? What do you want to
> accomplish? The indentation you showed looks alright to me.
>
Just that the java code won't compile because of the missing semi :)
Nothing more.
>> I see the tree-sitter playground [0] returns:
>> ```
>>
>>
>> program [0, 0] - [8, 0]
>> class_declaration [0, 0] - [6, 1]
>> name: identifier [0, 6] - [0, 9]
>> body: class_body [0, 10] - [6, 1]
>> method_declaration [1, 4] - [5, 6]
>> modifiers [1, 4] - [1, 10]
>> type: void_type [1, 11] - [1, 15]
>> name: identifier [1, 16] - [1, 19]
>> parameters: formal_parameters [1, 19] - [1, 21]
>> body: block [1, 22] - [5, 6]
>> local_variable_declaration [2, 8] - [3, 18]
>> type: type_identifier [2, 8] - [2, 11]
>> declarator: variable_declarator [2, 12] - [3, 18]
>> name: identifier [2, 12] - [2, 13]
>> value: method_invocation [2, 16] - [3, 18]
>> object: identifier [2, 16] - [2, 19]
>> name: identifier [3, 13] - [3, 16]
>> arguments: argument_list [3, 16] - [3, 18]
>> MISSING ; [3, 18] - [3, 18]
>> ```
>>
>> Which in turn could be something new not supported in the version I run?
>
> The explorer probably did something wrong and added the "type:"
> field name to the ";" node. Other than that I think the two parse tree
> should agree with each other.
>
> Yuan
Right, thanks!
bug marked as fixed in version 29.1, send any further explanations to
60751 <at> debbugs.gnu.org and Theodor Thornhill <theo <at> thornhill.no>
Request was from
Yuan Fu <casouri <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Sun, 15 Jan 2023 09:27:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 12 Feb 2023 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 65 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.