Received: (at 75154) by debbugs.gnu.org; 5 Jan 2025 11:29:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 06:29:31 2025
Received: from localhost ([127.0.0.1]:60148 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tUOp0-0004y1-Lu
for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 06:29:31 -0500
Received: from mx.kolabnow.com ([212.103.80.154]:45536)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <theo@HIDDEN>) id 1tUOoy-0004xl-9m
for 75154 <at> debbugs.gnu.org; Sun, 05 Jan 2025 06:29:29 -0500
Received: from localhost (unknown [127.0.0.1])
by mx.kolabnow.com (Postfix) with ESMTP id 4A2E4209201D;
Sun, 5 Jan 2025 12:29:22 +0100 (CET)
Authentication-Results: ext-mx-out011.mykolab.com (amavis);
dkim=pass (2048-bit key) reason="pass (just generated, assumed good)"
header.d=kolabnow.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kolabnow.com; h=
content-transfer-encoding:content-type:content-type:mime-version
:message-id:date:date:references:in-reply-to:subject:subject
:from:from:received:received:received; s=dkim20240523; t=
1736076560; x=1737890961; bh=mkzc2t0Y9UNkRoIaibihM2D+jADTezR9vNr
3w72G1/k=; b=Z4rqyUwbeRqdR63YxTMT8PjXGVhBgVJRnSzQf1G5DKCVxrLY24R
9fNbXE4acIKmTwrzdz8F0pgUg5x1nkde8uRF9PwwgISTrhNFwazui3hHWlLzXpHD
HUuVIvomhMV/on91oKd0VWxHZHJa3WrCm54LCTD4iEoc1BlDNr3oBoUyes3Ip/SR
G/Xs13/VGuNKNEIkWYnDKJuDqFsG3lPl89w0Hy8tyY6gpZjxoVokhDGvfBsRzNGW
a7t8oWOYAIGvM+1jcOQQQ/SAcBOHD/8AWKP2Rv0TQe5iKcUX/X0zTzSijkrYwIDT
RLBdJjQZe+SqgdfnXD7kkdeNr0VgwqRwmJQ==
X-Virus-Scanned: amavis at mykolab.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level:
X-Spam-Status: No, score=-1 tagged_above=-10 required=5 tests=[ALL_TRUSTED=-1]
autolearn=ham autolearn_force=no
Received: from mx.kolabnow.com ([127.0.0.1])
by localhost (ext-mx-out011.mykolab.com [127.0.0.1]) (amavis, port 10024)
with ESMTP id RdIbjTYF4ZaA; Sun, 5 Jan 2025 12:29:20 +0100 (CET)
Received: from int-mx011.mykolab.com (unknown [10.9.13.11])
by mx.kolabnow.com (Postfix) with ESMTPS id 76C1E2092013;
Sun, 5 Jan 2025 12:29:18 +0100 (CET)
Received: from ext-subm010.mykolab.com (unknown [10.9.6.10])
by int-mx011.mykolab.com (Postfix) with ESMTPS id 3CF1D313E1FE;
Sun, 5 Jan 2025 12:29:18 +0100 (CET)
From: Theodor Thornhill <theo@HIDDEN>
To: Stefan Kangas <stefankangas@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#75154: 31.0.50; java-ts-mode. Issues with Indentation
In-Reply-To: <CADwFkmmEZ8bQE+eFRUUmyg8vTq802Yfon_RsNB87ugpGhdmOUQ@HIDDEN>
References: <87ttapdtre.fsf@void> <86pllcurry.fsf@HIDDEN>
<CADwFkmmEZ8bQE+eFRUUmyg8vTq802Yfon_RsNB87ugpGhdmOUQ@HIDDEN>
Date: Sun, 05 Jan 2025 12:29:16 +0100
Message-ID: <87h66dv6r7.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75154
Cc: 75154 <at> debbugs.gnu.org, Artem <snake05865@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Hello, Artem!
>=20
> I've identified several issues with indentation in java-ts-mode where it
> doesn't work as expected. Let me first clarify
> what I consider "expected" behavior - there are things that are "GOOD",
> "BAD but allowed", and "Opinion-based.
>
Thanks for taking the time for this.
> Here are the specific problems:
>=20
> 1) Chaining Methods in the Stream API and Lambda Expressions
> Example 1:
> class Foo {
> void Foo() {
> List<Customer> customers =3D customer
> | <-- Actual (BAD)
> | <-- Expected (GOOD) (8 spaces)
> }
> }
> When continuing the statement
> List<Customer> customers =3D customer
> .stream
> and then adding closing parentheses=20=20=20=20=20=20=20=20
> List<Customer> customers =3D customer
> .stream() <-- The method filter will move to 4 spaces automati=
cally
> .filter <-- without parentheses=20
> .filter() <-- closing bracet and method moving to 4 spaces
>=20
> This behavior is problematic. In java-mode, this does not occur.IntelliJ
> IDEA uses 8 spaces for method chains,which makes the code more readable.
> While some examples use 2 spaces (e.g., for web snippets),in production
> environments, 8 spaces are more common. This should ideally be customizab=
le for end users.
>
Yes, while I do agree, this is kind of expected. Let me explain:
class Foo {
void Foo() {
List<Customer> customers =3D customer
| <-- Actual (BAD)
| <-- Expected (GOOD) (8 spaces)
}
}
This case boils down to two things. Personally I disagree with intellij
and the 8 indent case, but that is a stylistic thing, and not very
interesting, compared to the other thing. IIRC when I implemented this
there are some ambiguities when we get these unfinished statements.
Given your snippet here the parse tree is:
```
(program
(class_declaration class name: (identifier)
body:=20
(class_body {
(method_declaration type: (void_type) name: (identifier)
parameters: (formal_parameters ( ))
body:=20
(block {
(local_variable_declaration
type:=20
(generic_type (type_identifier)
(type_arguments < (type_identifier) >))
declarator: (variable_declarator name: (identifier) =3D value: (ide=
ntifier))
type: ;)
}))
})))
```
The interesting thing here is the `declarator` line, that ends in
identifier. That identifier is the symol `customer`. To know that we
have to indent here isn't really easy, at least not without interfering
with other constructs. The reason is that while you know that you want
to continue the chain, the parser actually ERRORs:
Given this code,
class Foo {
void Foo() {
List<Customer> customers =3D customer
.
=20=20=20=20=20=20=20=20=20
}
}
the parse tree is
(program
(ERROR class (identifier) { type: (void_type) name: (identifier)
parameters: (formal_parameters ( ))
{
(generic_type (type_identifier)
(type_arguments < (type_identifier) >))
name: (identifier) =3D (identifier) . } }))
While this is probably catchable, the "workaround" I started using is to
end the statement with a semi, then RET:
```
class Foo {
void Foo() {
List<Customer> customers =3D customer
|; // Point is now at |
=20=20=20=20=20=20=20=20=20
}
}
```
Now we have a valid parse tree, indented correctly, and can continue
chaining. I agree that this very much is a hack, but frankly I just
started doing that and forgot about it.
We could try to implement some acrobatics to fix this, but I'm too
limited for time right now to prioritize this one in particular. Feel
free to explore a patch that I can review!
> Moreover, the current indentation is hardcoded and doesn=E2=80=99t allow
> flexibility. For instance, in python-ts-mode, pressing TAB allows you to
> adjust constructions more freely.
> This level of flexibility would be beneficial in this context
>=20
> This inflexibility prevents writing common patterns like:
> @Override
> protected void configure(HttpSecurity http) throws Exception {
> http
> .authorizeRequests()
> .antMatchers("/admin/**").hasAuthority("ADMIN")
> .antMatchers("/user").hasAnyAuthority("USER", "ADMIN")
> .antMatchers("/", "/index").permitAll()
> Example 2:
>=20
> The following looks correct -
>=20
> public class FloodFill {
> public static void main(String[] args) {
> List<Foo> stream =3D students.stream()
> .filter(item -> {
> return item.getValue() > 100 &&
> item.isActive();
> })
> .map()
> .collect();
> }
> }
>=20
> But java-ts-mode produces:
>=20
> public class FloodFill {
> public static void main(String[] args) {
> List<Foo> stream =3D students.stream()
> .filter(item -> {
> return item.getValue() > 100 &&
> item.isActive();
> })
Yes, this really annoys me too, so I should try to fix this. I don't
remember from the top of my head what the problem was, but it forced me
either to omit the curlies, or just extract the body into a function and
pass it. But we should absolutely fix this. I believe there were several
difficulties here, where some are related to incomplete statements, and
some is related to treesit.el and the java parser idiosyncrasies. But
this is a valid bug in an of itself. If not too much of a hassle, could
you create a separate bugreport just for this case?
> .map()
> .collect();
> }
> }
>=20
> 2) Inner Classes
> Example 1:
> public class Outer {
> class Inner {| <-- cursor here moves Inner class unexpectedly
>=20
> }
> }
> Example 2:
> public class Outer {
> class Inner { // ???
> | <-- cursor here.=20=20=20=20=20=20=20=20=20=20=20
> }
> }
>=20
> Why does this happen? I did not request this behavior. While Example 1
> demonstrates bad code style, it is technically valid. Such "magical"
> formatting should be handled by a Java formatter, not by Emacs or
> Tree-sitter rules.
> IntelliJ IDEA does not apply such formatting; it leaves this task to the =
formatter.
>
This is due to electric indent. You could disable it yourself in your
config or just live with it. Emacs is by convention quite heavy handed
in trying to keep a consistent indent style, almost to the order of
acting like a formatter, rather than a simple indent offset
calculator. I also was confused when I started using Emacs, but now I
actually like this, as it feels more deterministic than other editors,
for better or worse.
> Example 3:
> public class Outer {
> class Inner{
> void foo(){
> }|<--start position. RET
> |<-- expected position
> |<-- actual
> }
> }
>=20
> If Inner class has incorrect indentation, subsequent code will also be in=
correctly indented.
>
I would rather inverse the statement, and say that subsequent code is
correctly indented, but the preceding code is ignored. As the correct
code is
```
public class Outer {
class Inner{
void foo(){
}
=20=20=20=20=20=20=20=20
}
}
```
Indentation at column 8 is expected here, IMO. I'm not sure we should
try to work around clearly "incorrectly" indented code.
> 3) for, if, else if, while, do-while without braces
> public class While {
> {
> while ()
> | <-- Expected=20=20=20=20=20=20
> | <-- Actual
> }
> }
> Although this is bad coding style, it=E2=80=99s allowed and compiles
> correctly.
This looks like several issues to me:
1. The block isn't handled correctly, as in it misses a rule. Line two
should be indented 4 spaces, but is indented 0 spaces on my system,
right?
2. The parse tree returns an ERROR, so I think this likely is a parser
bug rather than emacs bug to begin with. Though I believe the case
should be handled when the parser supports this.
```
(program
(class_declaration
(modifiers public)
class name: (identifier)
body:=20
(class_body {
(block {
(ERROR while ( ))
})
})))
```
Could you supply a separate bug report for this one?
>=20
> 4) Java 15 text blocks
> Text blocks are not properly handled
>=20
> public class TextBlocks {
> System.out.println(ctx.fetch("""
> SELECT table_schema, count(*)
> FROM information_schema.tables
> """));
> }
This isn't valid java is it? I changed it to=20
```
public class TextBlocks {
public void foo() {
System.out.println(ctx.fetch("""
SELECT table_schema, count(*)
FROM information_schema.tables
"""));
=20=20=20=20=20=20=20=20
}=20=20=20=20
}
```
>=20
> - Triple quotes handling (should electric-pair-mode be enhanced?)
Yes, I agree.
> - Text block alignment is opinion-based and should be adjustable with
> TAB
I usually indent stuff like this marking the region then using C-x i
then <left> or <right>
> - New SQL expressions should be sticky
What do you mean here? Align the newlines to the previous line?
> It seems such multiline strings also do not work well, for example:
> "'The time has come,' the Walrus said,\n" +
Not sure I understand what you mean here
>=20
>=20
> 5) Broken Syntax Highlighting
>=20
> public class Outer {
> HELLO EMACS <-- Write something here
> class Inner{ <-- This class will not be highlighted
> void foo(){
> }
>=20
> }
> }
> Tree-sitter should ignore such uncommon cases to maintain syntax highligh=
ting
This I believe is out of scope, but could be an issue for tree-sitter
upstream. We have to deal with the parse tree we get. How does neovim or
other editors handle this?
>=20
> 6) Multiple Parameters in Methods
> Example 1
> public record StudentRecord(
> String firstName,=20
> String lastName,=20
> Long studentId,=20
> String email)
What is wrong here?
> Example 2
> public String filterData(@RequestParam(required =3D false) String name,
> @RequestParam(required =3D false) String name,
> @RequestParam(required =3D false) Integer age
> )
> java-ts-mode fails to handle these cases correctly.
>
How so?
> Desired Fontification (Out of the Box):
> - Annotations (@Annotations)
> - Diamond Brackets (<>)
> - Constants, Static Variables, Enum Variables should be highlighted with
> distinct colors and optionally italic font
> - Unused Variables or Classes (Grayed Out)
This feels more like opinions rather than errors, but feature requests
are always welcome, of course. You could try to add patches for some of
these that I can review?
> - Unused variables, unused classes, etc., highlighted in gray. Not sure i=
f this can be achieved
> with Tree-sitter. Anyway, with Flymake + Eglot, it currently works in a s=
omewhat clunky manner.
>
This isn't possible with tree sitter. How is eglot clunky here? I'm kind
of satisfied, at least when the lsp actually marks these.
> Example
> public class TextBlocks {
> enum AnEnum { CONST1, CONST2 } <-- No effect for unused AnEnum.
> public static final String HELLO =3D"HELLO";
>=20
> public static void main(String[] args) {
> int i =3D 0; <-- Flymake identifies as unused but looks unpolishe=
d.=20
> System.out.println(HELLO);
> }
> }
>
This isn't treesit related, but could be a report for flymake
maintainers. We need to get the information from the server, though.
> Overall:
>=20
> I may have missed some aspects, but as it stands, Emacs is not
> comfortable for Java development with these issues.
>
Can you provide some sort of priority here? Most feel cosmetic, but
there are some real bugs here. One issue I also want, but is not quite
sure how to fix yet is the inline sql. We could try to do some multi
mode sql syntax highlighting here, possibly.
As another data point - I use Emacs for java development as the sole
emacs user on my team in a sea of Intellij users, and I don't really
share the view that it isn't comfortable for Java development. There is
a quirk here and there, sure, but I'm just as productive as everyone
else there. For me the biggest issue is the one case you mentioned here
with nested blocks inside of a chain of methods.
> Some information that might be helpful:
>=20
> - https://github.com/dakrone/eos/blob/dd8aa3a25b496397dd0162d229de5719896=
68619/eos-java.org?plain=3D1#L30
> .Not sure why this Elasticsearch developer created so many custom rules f=
or indentation.
> - https://github.com/Michael-Allan/Java_Mode_Tamed A major Java mode
> with sensible fontification.
This is c mode related, so not easy to relate to the treesit mode. But I
wasn't aware of this
> - JetBrains Intellij IDEA Community Edition
> - File>Settings>Editor>Color Scheme>Java Java for understanding which c=
olors are needed and what is missing.
> - Editor>Color Scheme>Java>Code Style>Java for indentation settings.
>
I'm not sure we should consider what Intellij does as a factual
source. Though it is for now the canonical java editor, who knows for
how long, and it feels time consuming to jump after a moving target.
Hope some of these comments are helpful, feel free to either provide
patches or disagree :-)
Theo
bug-gnu-emacs@HIDDEN:bug#75154; Package emacs.
Full text available.Stefan Kangas <stefankangas@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.
Received: (at 75154) by debbugs.gnu.org; 2 Jan 2025 01:24:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 01 20:24:01 2025
Received: from localhost ([127.0.0.1]:41109 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tT9wP-0000IC-0m
for submit <at> debbugs.gnu.org; Wed, 01 Jan 2025 20:24:01 -0500
Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]:44169)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>)
id 1tT9wN-0000Ht-9U
for 75154 <at> debbugs.gnu.org; Wed, 01 Jan 2025 20:23:59 -0500
Received: by mail-ed1-x533.google.com with SMTP id
4fb4d7f45d1cf-5d3e6274015so19110048a12.0
for <75154 <at> debbugs.gnu.org>; Wed, 01 Jan 2025 17:23:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1735781033; x=1736385833; darn=debbugs.gnu.org;
h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
:from:from:to:cc:subject:date:message-id:reply-to;
bh=iE25oi9v+V2zYfQ1opWysVIBhaFBofF+i+YDaaxoCPc=;
b=dUDSK1hM+3v/EclYuAAGc3ZI2KbrNM+Z9d4ZCfTHwflwbeS9lxprDOhd1T37+3zhOr
LqZnxNCHLpEUDz2gpakjB7azPY1SF7Qp4FdxO4goRFDj9V7d4lXraZ95W0fZ7MeTPLts
f4IL50oi25NnNzzOhi7sQvuI2HXeP491CXHU990Px5jgQ7HHDmbTdSJq1sTuW2q1YHEw
PN4z1lX3YZXEaU+akdlwg3DwEIZR5xKY41E7KjAIrs9W8xGg9YbNypjQR23jyNRp3Cvd
a1tee8mR/Vm9Wg3mfrpabZNcrvXj45/9sAxo0Wu/X185ZH6B5eHjpCCyC7Vn3irx9Yix
WjXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1735781033; x=1736385833;
h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
:from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=iE25oi9v+V2zYfQ1opWysVIBhaFBofF+i+YDaaxoCPc=;
b=smHbDyc6w+I/EjS+8usdmcXUbw2fX/A/rChJ+WGez8EKKFtYivKpeVD3GasuksVkbj
HNSeCXSUZd2rj7ULynTNmsxhxyPOJ2SzEdqQvns/Mtm3RzDOW/moq86wIO2Iu04WY5KH
K793CLyMIPSBgMpDUsdn5jw2O/IuIOMPTicmT8rfRZ9esLPhVAfT0yjjd4uJuAyi6t4x
Tp7t5MF7tBizzpnzMcmbTSaZMzplItDdEJDY6A37coWjqsJ7tzO35WUttKCFZtQuX44P
4qOZJ9cZit7SQJYvw9PMsiA6eX2geRkBty1J85ok+2yj3cr/fsszsA1r1mts6jR8J5Ac
lfOQ==
X-Forwarded-Encrypted: i=1;
AJvYcCUFK61Aq//Bb2/AZMP9K0guDtIfFJK92DVXuwm1CYXjXNslRVLzPRypQREPhTFZ+bEXV21DNg==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YxSMuwP+PSZhZU0unkRq60IDBvwJNZHX398Db0VYmHnqGO7E0zD
mrwuxj2eldZoLSZHGSoHlUosngUZi72C4AXwYJplTDozZ6GTFyfUUHgc7pQ0K99vO2WjyPKFd3S
5v4N2cTGvktcpGZeidSmKZfHXurVGpIFV
X-Gm-Gg: ASbGncsWkTa1SPdpFQ4Gcq0I5OzRmUp5s2T13aooQAn1aNwSz5d9I6Im2Q2+RGFUCSR
qQGFq/3DUVrs04MPJMDCSb9ncgQxjZcw8yhjazwEs
X-Google-Smtp-Source: AGHT+IEWIDaV2sXMJp6cLTGVixBHIQKX+tEyEqlpbGGscyIZ6RCAJRRtfr7kG1vXq1EJN/goQpYtrLtq1nyJuw6sorU=
X-Received: by 2002:a05:6402:400c:b0:5d0:9081:792f with SMTP id
4fb4d7f45d1cf-5d81ddbf39emr44748700a12.16.1735781033216; Wed, 01 Jan 2025
17:23:53 -0800 (PST)
Received: from 753933720722 named unknown by gmailapi.google.com with
HTTPREST; Wed, 1 Jan 2025 19:23:53 -0600
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <86pllcurry.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 28 Dec
2024 10:37:53 +0200")
References: <87ttapdtre.fsf@void> <86pllcurry.fsf@HIDDEN>
MIME-Version: 1.0
Date: Wed, 1 Jan 2025 19:23:52 -0600
Message-ID: <CADwFkmmEZ8bQE+eFRUUmyg8vTq802Yfon_RsNB87ugpGhdmOUQ@HIDDEN>
Subject: Re: bug#75154: 31.0.50; java-ts-mode. Issues with Indentation
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75154
Cc: 75154 <at> debbugs.gnu.org, Theodor Thornhill <theo@HIDDEN>,
Artem <snake05865@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Eli Zaretskii <eliz@HIDDEN> writes:
>> From: Artem <snake05865@HIDDEN>
>> Date: Fri, 27 Dec 2024 18:34:45 +0300
>>
>> 2) Inner Classes
>> Example 1:
>> public class Outer {
>> class Inner {| <-- cursor here moves Inner class unexpectedly
>>
>> }
>> }
>> Example 2:
>> public class Outer {
>> class Inner { // ???
>> | <-- cursor here.
>> }
>> }
>>
>> Why does this happen?
>
> Crystal ball says this is because electric-indent-mode is turned on
> (it is turned on by default in Emacs).
Theodor, any comments here?
bug-gnu-emacs@HIDDEN:bug#75154; Package emacs.
Full text available.
Received: (at 75154) by debbugs.gnu.org; 28 Dec 2024 08:38:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 28 03:38:04 2024
Received: from localhost ([127.0.0.1]:48674 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tRSKi-0007us-Fs
for submit <at> debbugs.gnu.org; Sat, 28 Dec 2024 03:38:04 -0500
Received: from eggs.gnu.org ([209.51.188.92]:59410)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1tRSKg-0007uL-I3
for 75154 <at> debbugs.gnu.org; Sat, 28 Dec 2024 03:38:03 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1tRSKb-0006xa-53; Sat, 28 Dec 2024 03:37:57 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=UHBRhi9PNaywch5N7zlO3AHSrkVPpukaZClybBQu/RE=; b=huyoOI3U8AUR
yJ5Q/Evk8uJke8IdGDBXNGQGK7c4SG+SNQXd1XwO7ZNy2YR6tAjkKZYN979Rwit5qAeLO2p1w8+gS
/dtL7x6IcJIf549JRdEh7Ih9PiT/9bzUcjw47QK4x2Zhlz3nfnKIyWpO9PPlnC8DWQzo8/aMTmJpU
vcxqrpIb1tetxrYchVFxBaUDwD+yyVwOC2mXzQdupPBlALkrXHeqyIRNxrguCw4eJpHHJ9EXhPPDO
IJLqbAcFK4Ar4IDul7FBqAHYaX89bt5t6UpsmWj8z2TIOCPrUrp23g7yUVTIenSlDE4KQfYgDpzGH
QHwunG/2mb5Lq2Foxz9q6w==;
Date: Sat, 28 Dec 2024 10:37:53 +0200
Message-Id: <86pllcurry.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Artem <snake05865@HIDDEN>
In-Reply-To: <87ttapdtre.fsf@void> (message from Artem on Fri, 27 Dec 2024
18:34:45 +0300)
Subject: Re: bug#75154: 31.0.50; java-ts-mode. Issues with Indentation
References: <87ttapdtre.fsf@void>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 75154
Cc: 75154 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: Artem <snake05865@HIDDEN>
> Date: Fri, 27 Dec 2024 18:34:45 +0300
>
> 2) Inner Classes
> Example 1:
> public class Outer {
> class Inner {| <-- cursor here moves Inner class unexpectedly
>
> }
> }
> Example 2:
> public class Outer {
> class Inner { // ???
> | <-- cursor here.
> }
> }
>
> Why does this happen?
Crystal ball says this is because electric-indent-mode is turned on
(it is turned on by default in Emacs).
bug-gnu-emacs@HIDDEN:bug#75154; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 28 Dec 2024 04:37:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Dec 27 23:37:44 2024
Received: from localhost ([127.0.0.1]:48325 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tROa7-0004pE-Az
for submit <at> debbugs.gnu.org; Fri, 27 Dec 2024 23:37:44 -0500
Received: from lists.gnu.org ([209.51.188.17]:49462)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <snake05865@HIDDEN>) id 1tRCgh-0000nD-No
for submit <at> debbugs.gnu.org; Fri, 27 Dec 2024 10:55:45 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <snake05865@HIDDEN>)
id 1tRCgg-000495-Iq
for bug-gnu-emacs@HIDDEN; Fri, 27 Dec 2024 10:55:42 -0500
Received: from mail-ej1-x631.google.com ([2a00:1450:4864:20::631])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <snake05865@HIDDEN>)
id 1tRCge-0005OT-JJ
for bug-gnu-emacs@HIDDEN; Fri, 27 Dec 2024 10:55:42 -0500
Received: by mail-ej1-x631.google.com with SMTP id
a640c23a62f3a-a9e44654ae3so1191505066b.1
for <bug-gnu-emacs@HIDDEN>; Fri, 27 Dec 2024 07:55:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1735314938; x=1735919738; darn=gnu.org;
h=content-transfer-encoding:mime-version:message-id:date:subject:to
:from:from:to:cc:subject:date:message-id:reply-to;
bh=EMQhwMPvt/4FiyN6HxCDCYCzld/pRiwSf9loR/yV4+4=;
b=dcOFzf8p7r9R7NpTdwof6BxGonsfLim2E3hQxr8J8Fg+HSkk0SqDRbDs5/xvQCspEm
k+uH/GdMXMXl7XZiVO0bK0/WckXdfhmSi3XyxT3V1HahvqTb5emw7WkPl6Oj3Df8QL9n
NOlUfA0vxwRf5jGh6CK5RoRxZvLOhDVedOnf2iDyCkn9xYe3P6AYbw8a6IZOjgKgaiLB
WL4sSJLpmF0Q4nd+JMwDkcgK7/LmJBhO8uAESEjXwmUaBuNKuwd4Ejq6LRzZgpT6f9e/
3nwpS4gZ2+RMgUYDsBBWtB5r7dm/mSgZoCpAvDXE7dojf4r8d50Pak3W4W6pMyCzJ4iz
4K0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1735314938; x=1735919738;
h=content-transfer-encoding:mime-version:message-id:date:subject:to
:from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=EMQhwMPvt/4FiyN6HxCDCYCzld/pRiwSf9loR/yV4+4=;
b=wL3qeRYv74ZqmmVvYsar1uPLZ7OTx6FWL8eUTMAKuDltn9guIPsQXEUOaBAE9PmfP0
FNpnwBAVshDcRVFDftobB8bjL8UtiRdBd6MLz4rsBCQlN7euUtn4mBp41+99TwpC4CIK
V1/iUQi8/Oxz/FsYN4csskrtkBXjWK3lXf7imnA5KpfCerHYeU6BLypJddvFA7F5AeQ+
ej1oGMYpfL0Jd40x4JaWUDkukSN7n5PF7xj2JnOGEFLqD0brR+SA8gsc2Bn+on7+3csn
9Vbd/EoCFiRzOypn1o54KFxwxKm5b0fiALez0rZiEzeBOMaNX+U0EvDrY/p8pJuO1V0x
9gEw==
X-Gm-Message-State: AOJu0Yxm5wiBGN5Wk3pkfUr1c6D9UV5hOXAj+b4dknCPKa5PweLzntTA
7w8KrXT2M0uAhIJj332fvxR8F6FSChZpZe+UEGp2NtHzccCtRqi0F9mt09Ypzq4=
X-Gm-Gg: ASbGncuLXojWX4hZX0yRX5h9XQdZD52NB6bLNI8Q3SfCsRd87S8blWHXNrcIQ/v2pTp
jKdjs+BO8KmMnFcFHwc7XxMHjbK2BuqxoZaNspThT2S6czPxG8mKIoG6B8UEbdjYLsd5ri+CzdE
JWQAKIr1+QefG9DkUs/r3gMRAKb/RVsTEM/kCl9b96PA7uCncrg2ieUcb1H6BrCnvesSI1AhwJO
faDHctRmeRxC2OpXxltc0osNohb4rRQ3FkQ1duiko8=
X-Google-Smtp-Source: AGHT+IH1FBqXhvsGj8EXOiN8rf4lARgAw85I00gcaUqpX5g+fe8jYObkpw283MuLlxEhhRpwxwC8RA==
X-Received: by 2002:a17:907:97c6:b0:aa6:a9fe:46e5 with SMTP id
a640c23a62f3a-aac3366afbdmr2451025866b.53.1735314937976;
Fri, 27 Dec 2024 07:55:37 -0800 (PST)
Received: from void ([77.51.14.33]) by smtp.gmail.com with ESMTPSA id
a640c23a62f3a-aac0f06543asm1128334866b.175.2024.12.27.07.55.37
for <bug-gnu-emacs@HIDDEN>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 27 Dec 2024 07:55:37 -0800 (PST)
Received: from localhost (void [local])
by void (OpenSMTPD) with ESMTPA id 1739995c
for <bug-gnu-emacs@HIDDEN>; Fri, 27 Dec 2024 15:34:45 +0000 (UTC)
From: Artem <snake05865@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 31.0.50; java-ts-mode. Issues with Indentation
X-Debbugs-Cc:
Date: Fri, 27 Dec 2024 18:34:45 +0300
Message-ID: <87ttapdtre.fsf@void>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=2a00:1450:4864:20::631;
envelope-from=snake05865@HIDDEN; helo=mail-ej1-x631.google.com
X-Spam_score_int: -17
X-Spam_score: -1.8
X-Spam_bar: -
X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
UNPARSEABLE_RELAY=0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.1 (-)
X-Debbugs-Envelope-To: submit
X-Mailman-Approved-At: Fri, 27 Dec 2024 23:37:41 -0500
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)
Hello
I've identified several issues with indentation in java-ts-mode where it
doesn't work as expected. Let me first clarify
what I consider "expected" behavior - there are things that are "GOOD",
"BAD but allowed", and "Opinion-based.
Here are the specific problems:
1) Chaining Methods in the Stream API and Lambda Expressions
Example 1:
class Foo {
void Foo() {
List<Customer> customers =3D customer
| <-- Actual (BAD)
| <-- Expected (GOOD) (8 spaces)
}
}
When continuing the statement
List<Customer> customers =3D customer
.stream
and then adding closing parentheses=20=20=20=20=20=20=20=20
List<Customer> customers =3D customer
.stream() <-- The method filter will move to 4 spaces automatica=
lly
.filter <-- without parentheses=20
.filter() <-- closing bracet and method moving to 4 spaces
This behavior is problematic. In java-mode, this does not occur.IntelliJ
IDEA uses 8 spaces for method chains,which makes the code more readable.
While some examples use 2 spaces (e.g., for web snippets),in production
environments, 8 spaces are more common. This should ideally be customizable=
for end users.
Moreover, the current indentation is hardcoded and doesn=E2=80=99t allow
flexibility. For instance, in python-ts-mode, pressing TAB allows you to
adjust constructions more freely.
This level of flexibility would be beneficial in this context
This inflexibility prevents writing common patterns like:
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests()
.antMatchers("/admin/**").hasAuthority("ADMIN")
.antMatchers("/user").hasAnyAuthority("USER", "ADMIN")
.antMatchers("/", "/index").permitAll()
Example 2:
The following looks correct -
public class FloodFill {
public static void main(String[] args) {
List<Foo> stream =3D students.stream()
.filter(item -> {
return item.getValue() > 100 &&
item.isActive();
})
.map()
.collect();
}
}
But java-ts-mode produces:
public class FloodFill {
public static void main(String[] args) {
List<Foo> stream =3D students.stream()
.filter(item -> {
return item.getValue() > 100 &&
item.isActive();
})
.map()
.collect();
}
}
2) Inner Classes
Example 1:
public class Outer {
class Inner {| <-- cursor here moves Inner class unexpectedly
}
}
Example 2:
public class Outer {
class Inner { // ???
| <-- cursor here.=20=20=20=20=20=20=20=20=20=20=20
}
}
Why does this happen? I did not request this behavior. While Example 1
demonstrates bad code style, it is technically valid. Such "magical"
formatting should be handled by a Java formatter, not by Emacs or
Tree-sitter rules.
IntelliJ IDEA does not apply such formatting; it leaves this task to the fo=
rmatter.
Example 3:
public class Outer {
class Inner{
void foo(){
}|<--start position. RET
|<-- expected position
|<-- actual
}
}
If Inner class has incorrect indentation, subsequent code will also be inco=
rrectly indented.
3) for, if, else if, while, do-while without braces
public class While {
{
while ()
| <-- Expected=20=20=20=20=20=20
| <-- Actual
}
}
Although this is bad coding style, it=E2=80=99s allowed and compiles correc=
tly.
4) Java 15 text blocks
Text blocks are not properly handled
public class TextBlocks {
System.out.println(ctx.fetch("""
SELECT table_schema, count(*)
FROM information_schema.tables
"""));
}
- Triple quotes handling (should electric-pair-mode be enhanced?)
- Text block alignment is opinion-based and should be adjustable with TAB
- New SQL expressions should be sticky
It seems such multiline strings also do not work well, for example:
"'The time has come,' the Walrus said,\n" +
5) Broken Syntax Highlighting
public class Outer {
HELLO EMACS <-- Write something here
class Inner{ <-- This class will not be highlighted
void foo(){
}
}
}
Tree-sitter should ignore such uncommon cases to maintain syntax highlighti=
ng
6) Multiple Parameters in Methods
Example 1
public record StudentRecord(
String firstName,=20
String lastName,=20
Long studentId,=20
String email)
Example 2
public String filterData(@RequestParam(required =3D false) String name,
@RequestParam(required =3D false) String name,
@RequestParam(required =3D false) Integer age
)
java-ts-mode fails to handle these cases correctly.
Desired Fontification (Out of the Box):
- Annotations (@Annotations)
- Diamond Brackets (<>)
- Constants, Static Variables, Enum Variables should be highlighted with
distinct colors and optionally italic font
- Unused Variables or Classes (Grayed Out)
- Unused variables, unused classes, etc., highlighted in gray. Not sure if =
this can be achieved
with Tree-sitter. Anyway, with Flymake + Eglot, it currently works in a som=
ewhat clunky manner.
Example
public class TextBlocks {
enum AnEnum { CONST1, CONST2 } <-- No effect for unused AnEnum.
public static final String HELLO =3D"HELLO";
public static void main(String[] args) {
int i =3D 0; <-- Flymake identifies as unused but looks unpolished.=
=20
System.out.println(HELLO);
}
}
Overall:
I may have missed some aspects, but as it stands, Emacs is not
comfortable for Java development with these issues.
Some information that might be helpful:
- https://github.com/dakrone/eos/blob/dd8aa3a25b496397dd0162d229de571989668=
619/eos-java.org?plain=3D1#L30
.Not sure why this Elasticsearch developer created so many custom rules for=
indentation.
- https://github.com/Michael-Allan/Java_Mode_Tamed A major Java mode with s=
ensible fontification.
- JetBrains Intellij IDEA Community Edition
- File>Settings>Editor>Color Scheme>Java Java for understanding which col=
ors are needed and what is missing.
- Editor>Color Scheme>Java>Code Style>Java for indentation settings.
Artem <snake05865@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#75154; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.