Received: (at 75154) by debbugs.gnu.org; 29 Mar 2025 11:26:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 29 07:26:35 2025
Received: from localhost ([127.0.0.1]:57259 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tyUKg-0002We-3b
for submit <at> debbugs.gnu.org; Sat, 29 Mar 2025 07:26:34 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:41614)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tyUKR-0002W2-Ob
for 75154 <at> debbugs.gnu.org; Sat, 29 Mar 2025 07:26:20 -0400
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 1tyUKL-0004zv-B8; Sat, 29 Mar 2025 07:26:13 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
Date; bh=iq1oHjs4b77+tf+ZpSGQGslYLw7CPwFICG7Bb0RYdcw=; b=KB+aBpE5RepAmkz33hV/
LTL2ZcIXCx6/ddlWs7BRYPOakyt19HJbGwJ5coxP7rj32Utw9hkLmyxExQmUbO2wjgEdLDkZGbFrU
e6vH7N0t9FSsJIDgOynDxurZEb3CdGH5RTBmuMd7IX74Qt479nT7dGdjwkGFLElqB4UxCgNSOUxoD
HZzfAQ15mPOG4jyqKz8oBZcTCnV9d/0+GgWlhkJ1Jdx/rcRAZfQqaBE9NcDRBFxrJ4i88ZFYO2LAf
n2+dc9fyNAQ++/RVHg846Cq0r8MjbXRaEQALJ4MbR1mPEgl6DINuzEe6ZS0bTRNgyGo8YEQzEauTz
p8QMj9xt5k7r0A==;
Date: Sat, 29 Mar 2025 14:26:11 +0300
Message-Id: <86v7rs6pt8.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Yuan Fu <casouri@HIDDEN>
In-Reply-To: <A5A189C8-DEA5-45CE-B90F-F7A3BC2C82B2@HIDDEN> (message from
Yuan Fu on Sun, 16 Mar 2025 22:47:48 -0700)
Subject: Re: bug#75154: 31.0.50; java-ts-mode. Issues with Indentation
References: <87ttapdtre.fsf@void> <86pllcurry.fsf@HIDDEN>
<CADwFkmmEZ8bQE+eFRUUmyg8vTq802Yfon_RsNB87ugpGhdmOUQ@HIDDEN>
<87h66dv6r7.fsf@HIDDEN>
<87cyg7dod2.fsf@HIDDEN>
<05BB2FA6-8280-43CB-80A8-AC2A9F07F196@HIDDEN>
<87ldtogz36.fsf@HIDDEN> <864j02h6ks.fsf@HIDDEN>
<A5A189C8-DEA5-45CE-B90F-F7A3BC2C82B2@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 75154
Cc: 75154 <at> debbugs.gnu.org, theo@HIDDEN, stefankangas@HIDDEN,
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: -3.3 (---)
Ping! What else needs to be done here?
> From: Yuan Fu <casouri@HIDDEN>
> Date: Sun, 16 Mar 2025 22:47:48 -0700
> Cc: Artem Bliznetsov <snake05865@HIDDEN>,
> Theodor Thornhill <theo@HIDDEN>,
> 75154 <at> debbugs.gnu.org,
> stefankangas@HIDDEN
>
>
>
> > On Mar 9, 2025, at 1:54 AM, Eli Zaretskii <eliz@HIDDEN> wrote:
> >
> > Ping! Yuan, could you please respond, so we could make progress with
> > these issues?
>
> Yeah, to move this forward, I applied the patch I submitted and made some more changes suggested by Artem. Now everything in this report should be handled. And honestly I don’t want to put more work in java-ts-mode anymore. I don’t know java very well and there’s a million other tree-sitter things I need to do.
>
> >> From: Artem Bliznetsov <snake05865@HIDDEN>
> >> Cc: Theodor Thornhill <theo@HIDDEN>, 75154 <at> debbugs.gnu.org, Eli
> >> Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN>
> >> Date: Sun, 02 Mar 2025 01:34:05 +0300
> >>
> >>> Ok, I attached a patch-set, if you apply this patch-set on top of _latest master_, most of the fixable problems in this report should be fixed/improved. Now, let me reply each item:
> >>
> >> Thank you for your patch. I have tested your changes.
> >> During compilation, I encountered the following warning:
> >>
> >> In java-ts-mode--first-line-on-multi-line-string:
> >> java-ts-mode.el:105:68: Warning: Unused lexical argument ‘bol’
> >>
> >> However, everything seems to be working fine.
> >>
> >>> 1. In the patch I added java-ts-mode-method-chaining-indent-offset,
> >>> defaults to 8
> >>
> >> Thank you! That’s great. Most users accustomed to 8-space indentation
> >> will find the default setting comfortable. Those who prefer
> >> 4 spaces are also taken into account.
> >>
> >>> 2. Set electric-indent-chars to nil so it doesn’t indent the current
> >>> line when you press RET.
> >>
> >> Actually, setting electric-indent-chars to nil disables all automatic
> >> indentation. Now, I’m reconsidering whether the initial example I
> >> provided was perhaps misguided and beyond what should be expected.
> >>
> >> 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.
> >> }
> >> }
> >>
> >> Again, I compared this behavior with IntelliJ IDEA and
> >> wondered why it shouldn't work the same way here. Essentially,
> >> what are we violating if we write
> >>
> >> public class Outer {
> >> class Inner {}
> >> }
> >>
> >> There are no syntax errors, but class Inner is not indented.
> >> Yes, the indentation appears when pressing RET after {, but if we
> >> then remove the spaces before class Inner and press RET again
> >> after {, electric-indent corrects the indentation.
>
> On my machine this code snippet is indented correctly:
>
> public class Outer {
> class Inner {}
> }
>
> Might have to do with different tree-sitter grammar versions. But let’s focus on the bigger issues and move forward at the moment.
>
> >> On one hand, this seems reasonable. On the other hand, shouldn’t this
> >> be handled by an external formatter? This is a minor issue and may
> >> not require any changes.
>
> You can definitely use an external formatter. If you really just want indent behavior of other editors, try stupid-indent-mode (you can install it from MELPA I think).
>
> >>
> >>> 3. The indentation is fixed once you type a valid statement, this is
> >>> because tree-sitter needs something to generate a parse-tree. We
> >>> can add some heuristics that gives a more intuitive indentation
> >>> when the line is empty, eg, "if prev line is while and current line
> >>> is empty, indent one level", etc. But that’s a more complicated
> >>> feature and I’ll defer to Theo.
> >>
> >>>
> >>> 4.
> >>> - Triple quote support in electric-pair-mode -> let’s open a separate
> >>> bug report for it and have electric-pair-mode maintainer take a
> >>> look.
> >>
> >> Should I classify this as a bug report? I didn’t notice any feature
> >> request category in the bug tracker. This is a small improvement that
> >> would add some convenience. Triple-quoted text blocks are not
> >> exclusive to Java; many other languages use them as well.
>
> Sure, I don’t think the category matter too much.
>
> >>
> >>> - In general, TAB in Emacs prog modes indent to a fixed point, rather
> >>> than just inserting a tab.
> >>
> >> I wasn’t aware of how this works. I briefly tested python-ts-mode and
> >> noticed that TAB behaves more freely there.
>
> Because python’s semantics depends on indentation, so it’s impossible to know what’s the correct indentation. Anyway, as I said, try stupid-indent-mode.
>
> >>
> >>> I added a indent rule such that aligns a
> >>> line in a string block to the previous line, for the first line, it indents one level.
> >>>
> >>
> >>> 6. For the parameter indentation, I recently added
> >>> c-ts-common-baseline-indent-rules that can handle it correctly. So
> >>> if we remove the existing indent rule for the parameters and add
> >>> c-ts-common-baseline-indent-rules at the end so the indentation
> >>> falls back to it, the indentation would look like this:
> >>>
> >>> public class TextBlocks {
> >>> public record StudentRecord(String firstName,
> >>> String lastName,
> >>> Long studentId,
> >>> String email) {
> >>>
> >>> }
> >>>
> >>>
> >>> public String filterData(@RequestParam(required = false) String name,
> >>> @RequestParam(required = false) String name,
> >>> @RequestParam(required = false) Integer age
> >>> )
> >>> }
> >>>
> >>> Seems fair? Theo, WDYT?
> >>
> >> I tested it, and it works. But do you see how it behaves?
> >> I’m not sure how to describe it correctly, but it feels a bit odd.
> >> If issue #3 gets resolved, everything should look much better.
>
> Stupid-indent-mode should solve your problem. So I’ll leave it as-is for now.
>
> >>
> >>>> - Annotations (@Annotations)
> >>> It seems to work fine? What’s the problem that you see?
> >>
> >> That was my mistake. I didn’t check which face was being used—or
> >> whether there was one at all. By default, java-mode uses
> >> c-annotation-face,while java-ts-mode uses font-lock-constant-face.
> >> One inherits from the other. I use the Modus theme, so something may
> >> have changed there.I only noticed it because, without any additional
> >> configuration, java-mode highlighted annotations by default.
> >>
> >> Anyway, it’s not that important now.
> >>
> >>>> - Diamond Brackets (<>)
> >>> Same as above, what’s the desired behavior?
> >>
> >> I just tested it with emacs -q and didn’t see any specific face for <>
> >> in java-mode. I use the popular package rainbow-delimiters.el,
> >> which does highlight <> in java-mode, but it hasn’t been updated in
> >> a while and doesn’t work with java-ts-mode.Currently, java-ts-mode
> >> applies font-lock-operator-face to <>, =, ->, &&, and possibly other
> >> symbols.That doesn’t seem quite right—should all operators really be
> >> highlighted this way? Some users might prefer extensive syntax
> >> highlighting, but it feels excessive to me.
>
> What’s your treesit-font-lock-level? It’s 3 by default, and you shouldn’t get highlighting on operators unless the level is set to 4.
>
> >> For reference, IntelliJ IDEA also doesn’t highlight <> by default.
> >> It requires a third-party plugin for that. So I’m not sure whether
> >> this should be added or not. If it is, that would be a nice improvement.
>
>
> >>
> >>>> - Constants, Static Variables, Enum Variables should be highlighted with
> >>>> distinct colors and optionally italic font
> >>>
> >>> For constants, they aren’t highlighted in constant face because rules
> >>> for ‘definition’ and ‘expression’ feature overrides them with
> >>> variable-name face. We can fix this by either moving the ‘constant’
> >>> face after ‘definition’ and ‘expression’ feature, or remove the
> >>> :override flag for ‘definition’ and ‘expression’ feature. Theo, any
> >>> suggestions here?
> >>
> >> That would be great to implement! I’m not sure how to show you exactly
> >> how it "should" look. Is it possible to attach images here?
>
> Yes, just attach it to the email. And I moved the font-lock rule for constant below definition and expression. Now constants should be fontified correctly.
>
> >> Although, Theo might have IntelliJ IDEA CE installed, so he likely
> >> already knows how it can look visually appealing.
> >>
> >>>> - Unused Variables or Classes (Grayed Out)
> >>>> - Unused variables, unused classes, etc., highlighted in gray. Not
> >>> sure if this can be achieved
> >>>
> >>> Tree-sitter can’t do this. So the only option is to use eglot for it.
> >>
> >> Thanks for the clarification! I’ll try to look into this.
> >>
> >> ----
> >> By the way, I discovered something else today. In
> >> java-ts-mode--keywords, the following keywords are missing:
> >> boolean, byte, char, const, double, float,
> >> goto, int, long, short, super, this, void, permits, var, when, yield, _.
> >> According to the Java Language Specification
> >> https://docs.oracle.com/javase/specs/jls/se23/html/jls-3.html#jls-3.9,
> >> the keyword @interface should be removed since annotations are already
> >> handled separately, and interface is already in the list.
>
> I added the non-type keywords in. Types like boolean and byte are fontified as type, so they don’t need to be in the list. And this and super are handled differently. I removed @interface.
>
> >>> Finally, some suggestions on communication. As you said on reddit,
> >>> you’re not a native English speaker, so I can’t blame you, but some
> >>> minor changes to wording can make your message sound a lot kinder :)
> >>> For example, short and imperative sentences like "you understand?"
> >>> sounds harsh and condescending; OTOH something like "I hope you can
> >>> understand/get that..." is a lot better. As a rule of thumb, the less
> >>> certain and the longer your expression is, the softer it sounds ;-)
> >>>
> >>> Yuan
> >>
> >> Yes, it is true that English is not my native language. However, upon
> >> reviewing my messages,I understand that in certain instances, I was not
> >> sufficiently polite. I will make an effort to improve this.
> >> I regret that this occurred.
>
> Thanks for you consideration :-)
>
>
bug-gnu-emacs@HIDDEN:bug#75154; Package emacs.
Full text available.
Received: (at 75154) by debbugs.gnu.org; 17 Mar 2025 05:48:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 17 01:48:13 2025
Received: from localhost ([127.0.0.1]:53766 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tu3Ke-0008EM-D3
for submit <at> debbugs.gnu.org; Mon, 17 Mar 2025 01:48:13 -0400
Received: from mail-pl1-x62d.google.com ([2607:f8b0:4864:20::62d]:44505)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <casouri@HIDDEN>) id 1tu3KZ-0008Cj-IA
for 75154 <at> debbugs.gnu.org; Mon, 17 Mar 2025 01:48:09 -0400
Received: by mail-pl1-x62d.google.com with SMTP id
d9443c01a7336-223fb0f619dso62849875ad.1
for <75154 <at> debbugs.gnu.org>; Sun, 16 Mar 2025 22:48:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1742190481; x=1742795281; darn=debbugs.gnu.org;
h=to:references:message-id:content-transfer-encoding:cc:date
:in-reply-to:from:subject:mime-version:from:to:cc:subject:date
:message-id:reply-to;
bh=ssta9fe8NT8QxZT5ZRt4Jm/IkjTqOCCcnmDoyIoD8KM=;
b=Lltwell7bVPq9bgu8IKCnZOzZ2gJqqAQdEXNb4usH38xPZCuoijR9IGA/2ZxZUeXfI
Hsr8VKWzTyFH1V8cBO84lZ6HiouUC3ZMcIvb8ppf1+swttcwcj+8VAIa3Uz0clLPrw2v
ImGrUEgMPeiz7BPsq5CJdKtL5Yr22mXH5ilr1LaTazQzt6m9mkdkftV5tCInuEobFGst
HOKLTTdM8SzdbDdkUICX7rBKezrf1QPv/bWVER0E7oyxVnpRK6DaLRWjw8jwWneGrN2n
5UBownrksM+zBRZa1za0z9TsXozmftxgU91MciCT175bswgQKf8t2YKaCqNszGeU8kDj
xJxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1742190481; x=1742795281;
h=to:references:message-id:content-transfer-encoding:cc:date
:in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=ssta9fe8NT8QxZT5ZRt4Jm/IkjTqOCCcnmDoyIoD8KM=;
b=EHl1TpTMkOMtfTwCNkWRhgJssuOmTLwNJr4cAdNUxOwVxIugnbjAha8D8ADurDJHEG
+aRcjegvOAL6GRlTo08dwM8OSASVsfcPWHh8PIv67Ix1ea9Pt+TXViJwj8ZXyW1SYM/j
8quO/bqTpZM/KmTPnV35OxZ60SqU7bGbismxO4bhlwErjjmF+DxkpISKSOnL2suW5iu3
qnrJ06fyJgK9wmMg2dti6jT7UP2WuClULsFxeRECmdCeSI9Ly5flVgQ8CGEaXyZj4odK
XICNdei5aWVwlkYqfKIDkNo3OoDHLNXmEkB/1h0z9wU+sX001b0RotLVD40YYYpbYm1u
bhhw==
X-Forwarded-Encrypted: i=1;
AJvYcCVoq9XiIykcvD5Z8i4RKZ2vY+MESxO6DZUt6nv9JtAlhzcz1TeVTbujhfQewyTZhmXMbHclvA==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YyUA8uRiMWa5U7WmOcEeRG4+13yQcd6PEVT8OH5pnp1eIljTmVJ
0Hd/JMRO90KqqHFREW74dlM/mJkEM8MMVf+VB8I8Vf3wtmNvU8pb
X-Gm-Gg: ASbGncsCfYwcFmeP6BJ+dt2seuPiXxIWXe+y5gquiXWKKaM7F5Azma4qlH1Uzc33xPn
zv3hrIolx1ahfUcDRyd5H3FYmp7fP82OKfSLExQOb0at+YlVqLzMvwLsfnliVgrrf1TzGpSHGGT
BPfFclOhFJfsefhAwp1dr7c9XFBcZ7hPWLeqHDz+pBSdnRDSB9dmLudmlJqY6zQ1iSbH1X1bOgy
HqxwlbSHIpVoiDm4N/vaMaz9PJZKkxf/wjxydjLvs/o7WTkVZzVZ8kFzCRYZiTAUCB2sur7Xb8s
+AcEycOaBpbQZOjDBWUykx5U4oMIQQJZw8IupgZ6jnOuB7XuLL9C+iMDi1F3FkXlXh4z
X-Google-Smtp-Source: AGHT+IG+1hdv91tmHWS0Plub4QuM411TUJLDFlhMSQpmTqMMcGze2p6GxnocyXfHRQnh5eyc2lRZ3Q==
X-Received: by 2002:a05:6a00:a2a:b0:736:b101:aed3 with SMTP id
d2e1a72fcca58-7372236a7f6mr12971651b3a.1.1742190481037;
Sun, 16 Mar 2025 22:48:01 -0700 (PDT)
Received: from smtpclient.apple ([2601:646:8f81:6120:bdc3:5773:4360:6e1c])
by smtp.gmail.com with ESMTPSA id
d2e1a72fcca58-7371167e018sm6896325b3a.91.2025.03.16.22.47.59
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Sun, 16 Mar 2025 22:48:00 -0700 (PDT)
Content-Type: text/plain;
charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
Subject: Re: bug#75154: 31.0.50; java-ts-mode. Issues with Indentation
From: Yuan Fu <casouri@HIDDEN>
In-Reply-To: <864j02h6ks.fsf@HIDDEN>
Date: Sun, 16 Mar 2025 22:47:48 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <A5A189C8-DEA5-45CE-B90F-F7A3BC2C82B2@HIDDEN>
References: <87ttapdtre.fsf@void> <86pllcurry.fsf@HIDDEN>
<CADwFkmmEZ8bQE+eFRUUmyg8vTq802Yfon_RsNB87ugpGhdmOUQ@HIDDEN>
<87h66dv6r7.fsf@HIDDEN>
<87cyg7dod2.fsf@HIDDEN>
<05BB2FA6-8280-43CB-80A8-AC2A9F07F196@HIDDEN>
<87ldtogz36.fsf@HIDDEN> <864j02h6ks.fsf@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
X-Mailer: Apple Mail (2.3776.700.51)
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75154
Cc: 75154 <at> debbugs.gnu.org, Theodor Thornhill <theo@HIDDEN>,
stefankangas@HIDDEN, Artem Bliznetsov <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 (-)
> On Mar 9, 2025, at 1:54=E2=80=AFAM, Eli Zaretskii <eliz@HIDDEN> =
wrote:
>=20
> Ping! Yuan, could you please respond, so we could make progress with
> these issues?
Yeah, to move this forward, I applied the patch I submitted and made =
some more changes suggested by Artem. Now everything in this report =
should be handled. And honestly I don=E2=80=99t want to put more work in =
java-ts-mode anymore. I don=E2=80=99t know java very well and there=E2=80=99=
s a million other tree-sitter things I need to do.
>> From: Artem Bliznetsov <snake05865@HIDDEN>
>> Cc: Theodor Thornhill <theo@HIDDEN>, 75154 <at> debbugs.gnu.org, Eli
>> Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN>
>> Date: Sun, 02 Mar 2025 01:34:05 +0300
>>=20
>>> Ok, I attached a patch-set, if you apply this patch-set on top of =
_latest master_, most of the fixable problems in this report should be =
fixed/improved. Now, let me reply each item:
>>=20
>> Thank you for your patch. I have tested your changes.
>> During compilation, I encountered the following warning:
>>=20
>> In java-ts-mode--first-line-on-multi-line-string:
>> java-ts-mode.el:105:68: Warning: Unused lexical argument =E2=80=98bol=E2=
=80=99
>>=20
>> However, everything seems to be working fine.=20
>>=20
>>> 1. In the patch I added java-ts-mode-method-chaining-indent-offset,
>>> defaults to 8
>>=20
>> Thank you! That=E2=80=99s great. Most users accustomed to 8-space =
indentation
>> will find the default setting comfortable. Those who prefer
>> 4 spaces are also taken into account.
>>=20
>>> 2. Set electric-indent-chars to nil so it doesn=E2=80=99t indent the =
current
>>> line when you press RET.
>>=20
>> Actually, setting electric-indent-chars to nil disables all automatic
>> indentation. Now, I=E2=80=99m reconsidering whether the initial =
example I
>> provided was perhaps misguided and beyond what should be expected.
>>=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
>> Again, I compared this behavior with IntelliJ IDEA and
>> wondered why it shouldn't work the same way here. Essentially,
>> what are we violating if we write
>>=20
>> public class Outer {
>> class Inner {}
>> }
>>=20
>> There are no syntax errors, but class Inner is not indented.
>> Yes, the indentation appears when pressing RET after {, but if we
>> then remove the spaces before class Inner and press RET again
>> after {, electric-indent corrects the indentation.
On my machine this code snippet is indented correctly:
public class Outer {
class Inner {}
}
Might have to do with different tree-sitter grammar versions. But =
let=E2=80=99s focus on the bigger issues and move forward at the moment.
>> On one hand, this seems reasonable. On the other hand, shouldn=E2=80=99=
t this
>> be handled by an external formatter? This is a minor issue and may
>> not require any changes.
You can definitely use an external formatter. If you really just want =
indent behavior of other editors, try stupid-indent-mode (you can =
install it from MELPA I think).
>>=20
>>> 3. The indentation is fixed once you type a valid statement, this is
>>> because tree-sitter needs something to generate a parse-tree. We
>>> can add some heuristics that gives a more intuitive indentation
>>> when the line is empty, eg, "if prev line is while and current =
line
>>> is empty, indent one level", etc. But that=E2=80=99s a more =
complicated
>>> feature and I=E2=80=99ll defer to Theo.
>>=20
>>>=20
>>> 4.
>>> - Triple quote support in electric-pair-mode -> let=E2=80=99s open a =
separate
>>> bug report for it and have electric-pair-mode maintainer take a
>>> look.
>>=20
>> Should I classify this as a bug report? I didn=E2=80=99t notice any =
feature
>> request category in the bug tracker. This is a small improvement that
>> would add some convenience. Triple-quoted text blocks are not
>> exclusive to Java; many other languages use them as well.
Sure, I don=E2=80=99t think the category matter too much.
>>=20
>>> - In general, TAB in Emacs prog modes indent to a fixed point, =
rather
>>> than just inserting a tab.
>>=20
>> I wasn=E2=80=99t aware of how this works. I briefly tested =
python-ts-mode and
>> noticed that TAB behaves more freely there.
Because python=E2=80=99s semantics depends on indentation, so it=E2=80=99s=
impossible to know what=E2=80=99s the correct indentation. Anyway, as I =
said, try stupid-indent-mode.
>>=20
>>> I added a indent rule such that aligns a
>>> line in a string block to the previous line, for the first line, it =
indents one level.
>>>=20
>>=20
>>> 6. For the parameter indentation, I recently added
>>> c-ts-common-baseline-indent-rules that can handle it correctly. So
>>> if we remove the existing indent rule for the parameters and add
>>> c-ts-common-baseline-indent-rules at the end so the indentation
>>> falls back to it, the indentation would look like this:
>>>=20
>>> public class TextBlocks {
>>> public record StudentRecord(String firstName,
>>> String lastName,
>>> Long studentId,
>>> String email) {
>>>=20
>>> }
>>>=20
>>>=20
>>> public String filterData(@RequestParam(required =3D false) String =
name,
>>> @RequestParam(required =3D false) String =
name,
>>> @RequestParam(required =3D false) =
Integer age
>>> )
>>> }
>>>=20
>>> Seems fair? Theo, WDYT?
>>=20
>> I tested it, and it works. But do you see how it behaves?
>> I=E2=80=99m not sure how to describe it correctly, but it feels a bit =
odd.
>> If issue #3 gets resolved, everything should look much better.
Stupid-indent-mode should solve your problem. So I=E2=80=99ll leave it =
as-is for now.
>>=20
>>>> - Annotations (@Annotations)
>>> It seems to work fine? What=E2=80=99s the problem that you see?
>>=20
>> That was my mistake. I didn=E2=80=99t check which face was being =
used=E2=80=94or
>> whether there was one at all. By default, java-mode uses
>> c-annotation-face,while java-ts-mode uses font-lock-constant-face.
>> One inherits from the other. I use the Modus theme, so something may
>> have changed there.I only noticed it because, without any additional
>> configuration, java-mode highlighted annotations by default.
>>=20
>> Anyway, it=E2=80=99s not that important now.
>>=20
>>>> - Diamond Brackets (<>)
>>> Same as above, what=E2=80=99s the desired behavior?
>>=20
>> I just tested it with emacs -q and didn=E2=80=99t see any specific =
face for <>
>> in java-mode. I use the popular package rainbow-delimiters.el,
>> which does highlight <> in java-mode, but it hasn=E2=80=99t been =
updated in
>> a while and doesn=E2=80=99t work with java-ts-mode.Currently, =
java-ts-mode
>> applies font-lock-operator-face to <>, =3D, ->, &&, and possibly =
other
>> symbols.That doesn=E2=80=99t seem quite right=E2=80=94should all =
operators really be
>> highlighted this way? Some users might prefer extensive syntax
>> highlighting, but it feels excessive to me.
What=E2=80=99s your treesit-font-lock-level? It=E2=80=99s 3 by default, =
and you shouldn=E2=80=99t get highlighting on operators unless the level =
is set to 4.
>> For reference, IntelliJ IDEA also doesn=E2=80=99t highlight <> by =
default.
>> It requires a third-party plugin for that. So I=E2=80=99m not sure =
whether
>> this should be added or not. If it is, that would be a nice =
improvement.
>>=20
>>>> - Constants, Static Variables, Enum Variables should be highlighted =
with
>>>> distinct colors and optionally italic font
>>>=20
>>> For constants, they aren=E2=80=99t highlighted in constant face =
because rules
>>> for =E2=80=98definition=E2=80=99 and =E2=80=98expression=E2=80=99 =
feature overrides them with
>>> variable-name face. We can fix this by either moving the =
=E2=80=98constant=E2=80=99
>>> face after =E2=80=98definition=E2=80=99 and =E2=80=98expression=E2=80=99=
feature, or remove the
>>> :override flag for =E2=80=98definition=E2=80=99 and =E2=80=98expressio=
n=E2=80=99 feature. Theo, any
>>> suggestions here?
>>=20
>> That would be great to implement! I=E2=80=99m not sure how to show =
you exactly
>> how it "should" look. Is it possible to attach images here?
Yes, just attach it to the email. And I moved the font-lock rule for =
constant below definition and expression. Now constants should be =
fontified correctly.
>> Although, Theo might have IntelliJ IDEA CE installed, so he likely
>> already knows how it can look visually appealing.
>>=20
>>>> - Unused Variables or Classes (Grayed Out)
>>>> - Unused variables, unused classes, etc., highlighted in gray. Not
>>> sure if this can be achieved
>>>=20
>>> Tree-sitter can=E2=80=99t do this. So the only option is to use =
eglot for it.
>>=20
>> Thanks for the clarification! I=E2=80=99ll try to look into this.
>>=20
>> ----
>> By the way, I discovered something else today. In
>> java-ts-mode--keywords, the following keywords are missing:
>> boolean, byte, char, const, double, float,
>> goto, int, long, short, super, this, void, permits, var, when, yield, =
_.
>> According to the Java Language Specification
>> =
https://docs.oracle.com/javase/specs/jls/se23/html/jls-3.html#jls-3.9,
>> the keyword @interface should be removed since annotations are =
already
>> handled separately, and interface is already in the list.
I added the non-type keywords in. Types like boolean and byte are =
fontified as type, so they don=E2=80=99t need to be in the list. And =
this and super are handled differently. I removed @interface.
>>> Finally, some suggestions on communication. As you said on reddit,
>>> you=E2=80=99re not a native English speaker, so I can=E2=80=99t =
blame you, but some
>>> minor changes to wording can make your message sound a lot kinder :)
>>> For example, short and imperative sentences like "you understand?"
>>> sounds harsh and condescending; OTOH something like "I hope you can
>>> understand/get that..." is a lot better. As a rule of thumb, the =
less
>>> certain and the longer your expression is, the softer it sounds ;-)
>>>=20
>>> Yuan
>>=20
>> Yes, it is true that English is not my native language. However, upon
>> reviewing my messages,I understand that in certain instances, I was =
not
>> sufficiently polite. I will make an effort to improve this.
>> I regret that this occurred.
Thanks for you consideration :-)
bug-gnu-emacs@HIDDEN:bug#75154; Package emacs.
Full text available.
Received: (at 75154) by debbugs.gnu.org; 9 Mar 2025 09:55:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 09 05:55:14 2025
Received: from localhost ([127.0.0.1]:58417 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1trDNJ-0005kG-58
for submit <at> debbugs.gnu.org; Sun, 09 Mar 2025 05:55:14 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:51248)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1trDNG-0005iD-9U
for 75154 <at> debbugs.gnu.org; Sun, 09 Mar 2025 05:55:11 -0400
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 1trDNA-0008SY-Dv; Sun, 09 Mar 2025 05:55:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
Date; bh=Qff3iB170IYkrYwRs9GF1l7ZgWt26uFvfiGkhdtCK48=; b=Cakc4xmiUFRsJh9JV+gR
dOn8IQ/AJL6ej2eUwJdPbWZVRKAXkVHD1NV0A0suLx3XMSst5kTknOsmX3ftnF+0B6RGUCre65nbj
xuEDnvsHjepDqDONSACL0VyFIiodaCQDeHZsoHvNKWmTCGdRCZ0QckIBq5dwDlg2PpuNJJ0j4otsj
wk+StUjiZ344Ja7ycz1k8/N9R4SI50wy7M9yZMPT839/eyTmwCpEzF0o6lOkTXYhyMf7FZk/rRTVS
XyiU4rRSzBwtE1cEpBO6ENHH7Z5zgTem4qlnehOd2v8ZUonZ2K8VzbmWs5AAiWmsKggwvIv7vpnT3
OHHcirt9S/X0OQ==;
Date: Sun, 09 Mar 2025 11:54:59 +0200
Message-Id: <864j02h6ks.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: casouri@HIDDEN, Artem Bliznetsov <snake05865@HIDDEN>
In-Reply-To: <87ldtogz36.fsf@HIDDEN> (message from
Artem Bliznetsov on Sun, 02 Mar 2025 01:34:05 +0300)
Subject: Re: bug#75154: 31.0.50; java-ts-mode. Issues with Indentation
References: <87ttapdtre.fsf@void> <86pllcurry.fsf@HIDDEN>
<CADwFkmmEZ8bQE+eFRUUmyg8vTq802Yfon_RsNB87ugpGhdmOUQ@HIDDEN>
<87h66dv6r7.fsf@HIDDEN>
<87cyg7dod2.fsf@HIDDEN>
<05BB2FA6-8280-43CB-80A8-AC2A9F07F196@HIDDEN>
<87ldtogz36.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 75154
Cc: 75154 <at> debbugs.gnu.org, theo@HIDDEN, stefankangas@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: -3.3 (---)
Ping! Yuan, could you please respond, so we could make progress with
these issues?
> From: Artem Bliznetsov <snake05865@HIDDEN>
> Cc: Theodor Thornhill <theo@HIDDEN>, 75154 <at> debbugs.gnu.org, Eli
> Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN>
> Date: Sun, 02 Mar 2025 01:34:05 +0300
>
> > Ok, I attached a patch-set, if you apply this patch-set on top of _latest master_, most of the fixable problems in this report should be fixed/improved. Now, let me reply each item:
>
> Thank you for your patch. I have tested your changes.
> During compilation, I encountered the following warning:
>
> In java-ts-mode--first-line-on-multi-line-string:
> java-ts-mode.el:105:68: Warning: Unused lexical argument ‘bol’
>
> However, everything seems to be working fine.
>
> > 1. In the patch I added java-ts-mode-method-chaining-indent-offset,
> > defaults to 8
>
> Thank you! That’s great. Most users accustomed to 8-space indentation
> will find the default setting comfortable. Those who prefer
> 4 spaces are also taken into account.
>
> > 2. Set electric-indent-chars to nil so it doesn’t indent the current
> > line when you press RET.
>
> Actually, setting electric-indent-chars to nil disables all automatic
> indentation. Now, I’m reconsidering whether the initial example I
> provided was perhaps misguided and beyond what should be expected.
>
> 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.
> }
> }
>
> Again, I compared this behavior with IntelliJ IDEA and
> wondered why it shouldn't work the same way here. Essentially,
> what are we violating if we write
>
> public class Outer {
> class Inner {}
> }
>
> There are no syntax errors, but class Inner is not indented.
> Yes, the indentation appears when pressing RET after {, but if we
> then remove the spaces before class Inner and press RET again
> after {, electric-indent corrects the indentation.
>
> On one hand, this seems reasonable. On the other hand, shouldn’t this
> be handled by an external formatter? This is a minor issue and may
> not require any changes.
>
> > 3. The indentation is fixed once you type a valid statement, this is
> > because tree-sitter needs something to generate a parse-tree. We
> > can add some heuristics that gives a more intuitive indentation
> > when the line is empty, eg, "if prev line is while and current line
> > is empty, indent one level", etc. But that’s a more complicated
> > feature and I’ll defer to Theo.
>
> >
> > 4.
> > - Triple quote support in electric-pair-mode -> let’s open a separate
> > bug report for it and have electric-pair-mode maintainer take a
> > look.
>
> Should I classify this as a bug report? I didn’t notice any feature
> request category in the bug tracker. This is a small improvement that
> would add some convenience. Triple-quoted text blocks are not
> exclusive to Java; many other languages use them as well.
>
> > - In general, TAB in Emacs prog modes indent to a fixed point, rather
> > than just inserting a tab.
>
> I wasn’t aware of how this works. I briefly tested python-ts-mode and
> noticed that TAB behaves more freely there.
>
> >I added a indent rule such that aligns a
> > line in a string block to the previous line, for the first line, it indents one level.
> >
>
> > 6. For the parameter indentation, I recently added
> > c-ts-common-baseline-indent-rules that can handle it correctly. So
> > if we remove the existing indent rule for the parameters and add
> > c-ts-common-baseline-indent-rules at the end so the indentation
> > falls back to it, the indentation would look like this:
> >
> > public class TextBlocks {
> > public record StudentRecord(String firstName,
> > String lastName,
> > Long studentId,
> > String email) {
> >
> > }
> >
> >
> > public String filterData(@RequestParam(required = false) String name,
> > @RequestParam(required = false) String name,
> > @RequestParam(required = false) Integer age
> > )
> > }
> >
> > Seems fair? Theo, WDYT?
>
> I tested it, and it works. But do you see how it behaves?
> I’m not sure how to describe it correctly, but it feels a bit odd.
> If issue #3 gets resolved, everything should look much better.
>
> >> - Annotations (@Annotations)
> > It seems to work fine? What’s the problem that you see?
>
> That was my mistake. I didn’t check which face was being used—or
> whether there was one at all. By default, java-mode uses
> c-annotation-face,while java-ts-mode uses font-lock-constant-face.
> One inherits from the other. I use the Modus theme, so something may
> have changed there.I only noticed it because, without any additional
> configuration, java-mode highlighted annotations by default.
>
> Anyway, it’s not that important now.
>
> >> - Diamond Brackets (<>)
> > Same as above, what’s the desired behavior?
>
> I just tested it with emacs -q and didn’t see any specific face for <>
> in java-mode. I use the popular package rainbow-delimiters.el,
> which does highlight <> in java-mode, but it hasn’t been updated in
> a while and doesn’t work with java-ts-mode.Currently, java-ts-mode
> applies font-lock-operator-face to <>, =, ->, &&, and possibly other
> symbols.That doesn’t seem quite right—should all operators really be
> highlighted this way? Some users might prefer extensive syntax
> highlighting, but it feels excessive to me.
>
> For reference, IntelliJ IDEA also doesn’t highlight <> by default.
> It requires a third-party plugin for that. So I’m not sure whether
> this should be added or not. If it is, that would be a nice improvement.
>
> >> - Constants, Static Variables, Enum Variables should be highlighted with
> >> distinct colors and optionally italic font
> >
> > For constants, they aren’t highlighted in constant face because rules
> > for ‘definition’ and ‘expression’ feature overrides them with
> > variable-name face. We can fix this by either moving the ‘constant’
> > face after ‘definition’ and ‘expression’ feature, or remove the
> > :override flag for ‘definition’ and ‘expression’ feature. Theo, any
> > suggestions here?
>
> That would be great to implement! I’m not sure how to show you exactly
> how it "should" look. Is it possible to attach images here?
> Although, Theo might have IntelliJ IDEA CE installed, so he likely
> already knows how it can look visually appealing.
>
> >> - Unused Variables or Classes (Grayed Out)
> >> - Unused variables, unused classes, etc., highlighted in gray. Not
> > sure if this can be achieved
> >
> > Tree-sitter can’t do this. So the only option is to use eglot for it.
>
> Thanks for the clarification! I’ll try to look into this.
>
> ----
> By the way, I discovered something else today. In
> java-ts-mode--keywords, the following keywords are missing:
> boolean, byte, char, const, double, float,
> goto, int, long, short, super, this, void, permits, var, when, yield, _.
> According to the Java Language Specification
> https://docs.oracle.com/javase/specs/jls/se23/html/jls-3.html#jls-3.9,
> the keyword @interface should be removed since annotations are already
> handled separately, and interface is already in the list.
>
> > Finally, some suggestions on communication. As you said on reddit,
> > you’re not a native English speaker, so I can’t blame you, but some
> > minor changes to wording can make your message sound a lot kinder :)
> > For example, short and imperative sentences like "you understand?"
> > sounds harsh and condescending; OTOH something like "I hope you can
> > understand/get that..." is a lot better. As a rule of thumb, the less
> > certain and the longer your expression is, the softer it sounds ;-)
> >
> > Yuan
>
> Yes, it is true that English is not my native language. However, upon
> reviewing my messages,I understand that in certain instances, I was not
> sufficiently polite. I will make an effort to improve this.
> I regret that this occurred.
>
bug-gnu-emacs@HIDDEN:bug#75154; Package emacs.
Full text available.
Received: (at 75154) by debbugs.gnu.org; 1 Mar 2025 22:34:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 01 17:34:20 2025
Received: from localhost ([127.0.0.1]:45851 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1toVPX-0005PE-Bd
for submit <at> debbugs.gnu.org; Sat, 01 Mar 2025 17:34:20 -0500
Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]:44235)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <snake05865@HIDDEN>)
id 1toVPT-0005Nz-OY
for 75154 <at> debbugs.gnu.org; Sat, 01 Mar 2025 17:34:17 -0500
Received: by mail-wr1-x42c.google.com with SMTP id
ffacd0b85a97d-390df0138beso1763260f8f.0
for <75154 <at> debbugs.gnu.org>; Sat, 01 Mar 2025 14:34:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1740868449; x=1741473249; darn=debbugs.gnu.org;
h=content-transfer-encoding:mime-version:message-id:date:references
:in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id
:reply-to; bh=YWxsENgpUbza1rNbzyRC+vXSRuFS9D9wL/smaCCNF3Y=;
b=G1NNi6UbQHdIGtvWQxzXS2LsjnuaD87mVw+KueAoB4iJREcoCGWGR5X4lQuZOun7Ap
dY6lChimnNfMvsmcMzu1ss8g26wwnm2pRwFoV6FtHezTZTwwYy5B3pYEd3a94EByT8XQ
5nihwYqJqHFZNo5YoQroEjCK9df4dbhjG1AehI8zL7oso6EFbSJeBVXH3OoRFYqUpFT3
Bi9zp6zmlV8XNdK1U9Pyj0KWfaSLxQY+/7ZCVmi6yrIpJZh/xRGWV0Y5LlOMXYjTmokK
IQhkseyD5WuHhkHVJ1jWxdiwg8BArbi9kqlWmlrNXtUnLgK3tEmeeHhCTkX3wEBWrqxI
ZP0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1740868449; x=1741473249;
h=content-transfer-encoding:mime-version:message-id:date:references
:in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=YWxsENgpUbza1rNbzyRC+vXSRuFS9D9wL/smaCCNF3Y=;
b=nGVX8itNsKets/or6YjBpgnKsLBEZmrzmnI/9GE9rR23pYizgUx47ZNGTkTmPFUE8y
ngrUubkX5SHv+qdJM7H8U6wg1HOddlc3dREEIYs/rbJsmx+5Ic3Nzz46v6TYqlx0l0gZ
vm0+S3FjrvZkZ5NG0peryfs7xCSYH1oeaWriKrTJMQOlxgYW3pHpJkNI1zIB8RBsMYII
9M/lJWSzSjifDbfK9+sFedZzJ4k2bHYOSxdyksO0X9kEQJJQ82B/li/k/jHnMaKLGquK
PaO6KCvFGG1CssBdHts1LW3HUGUgV8IrNFbIkbz1YcPOkKxozMwLtTEvA+iksVZzYw6U
twhQ==
X-Forwarded-Encrypted: i=1;
AJvYcCW3UIbtw9U5LZPGEXBlCJ5B8gnMABCIRsGrwov/rSXwoSuE/X1/gdlc+6RN5xMKUPIwQG29lw==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YzJM5vTaSpA7Skytc4Pk7AorJDChOOi7ytR6/DXJi98UdUosI+s
mXXv7COhtke7Nax4i3dmnDAwxwlXavZM/rhN3yHHlXS46RFS3Nr3
X-Gm-Gg: ASbGncsiAao0JOvehqHsQ5BtscHi5VNPqX6n1Nenj/Epxm8Q8Fb7eQsIVUH3RMirRQh
CWoKtoom4cWLGB4RQskuszsiM4RKkD7jMGG5APoVSF3CjliQtmlrlbpDAUZTYVYOjT4aKscuGY+
MyFsbCHFkyGcFMpiut6GFW4RvAPo+jsjWPKOC4N19F41lO/208vbO46fmVQD2uIy6WlT5DXLqOa
nnzUV/Nf5XJPtdUwFpdcpEe7Cj5R8pU5YDX8ZnWshwT5FqmS0VExjo9+nELk4kvnDY5HJB1wgbI
Nc4ZGjQeWTeXK0khsOl2Ef1lczGTSxDAEOE=
X-Google-Smtp-Source: AGHT+IHC9ooKTgsjLP3VClITFLDZrA56s2zrgQaTY8jpVE9enATxmRZphzXLUx3TW/0+Q5lT4jsuyg==
X-Received: by 2002:a05:6000:1a86:b0:390:e9e7:ca70 with SMTP id
ffacd0b85a97d-390ec9c0ab0mr6619829f8f.30.1740868449035;
Sat, 01 Mar 2025 14:34:09 -0800 (PST)
Received: from void ([77.51.166.151]) by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-390e485e045sm9637241f8f.99.2025.03.01.14.34.06
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 01 Mar 2025 14:34:07 -0800 (PST)
Received: from localhost (void [local])
by void (OpenSMTPD) with ESMTPA id 190c0ad9;
Sat, 1 Mar 2025 22:34:05 +0000 (UTC)
From: Artem Bliznetsov <snake05865@HIDDEN>
To: Yuan Fu <casouri@HIDDEN>
Subject: Re: bug#75154: 31.0.50; java-ts-mode. Issues with Indentation
In-Reply-To: <05BB2FA6-8280-43CB-80A8-AC2A9F07F196@HIDDEN>
References: <87ttapdtre.fsf@void> <86pllcurry.fsf@HIDDEN>
<CADwFkmmEZ8bQE+eFRUUmyg8vTq802Yfon_RsNB87ugpGhdmOUQ@HIDDEN>
<87h66dv6r7.fsf@HIDDEN>
<87cyg7dod2.fsf@HIDDEN>
<05BB2FA6-8280-43CB-80A8-AC2A9F07F196@HIDDEN>
Date: Sun, 02 Mar 2025 01:34:05 +0300
Message-ID: <87ldtogz36.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 75154
Cc: 75154 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
Theodor Thornhill <theo@HIDDEN>, Stefan Kangas <stefankangas@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: -0.7 (/)
> Ok, I attached a patch-set, if you apply this patch-set on top of _latest=
master_, most of the fixable problems in this report should be fixed/impro=
ved. Now, let me reply each item:
Thank you for your patch. I have tested your changes.
During compilation, I encountered the following warning:
In java-ts-mode--first-line-on-multi-line-string:
java-ts-mode.el:105:68: Warning: Unused lexical argument =E2=80=98bol=E2=80=
=99
However, everything seems to be working fine.=20
> 1. In the patch I added java-ts-mode-method-chaining-indent-offset,
> defaults to 8
Thank you! That=E2=80=99s great. Most users accustomed to 8-space indentati=
on
will find the default setting comfortable. Those who prefer
4 spaces are also taken into account.
> 2. Set electric-indent-chars to nil so it doesn=E2=80=99t indent the curr=
ent
> line when you press RET.
Actually, setting electric-indent-chars to nil disables all automatic
indentation. Now, I=E2=80=99m reconsidering whether the initial example I
provided was perhaps misguided and beyond what should be expected.
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
}
}
Again, I compared this behavior with IntelliJ IDEA and
wondered why it shouldn't work the same way here. Essentially,
what are we violating if we write
public class Outer {
class Inner {}
}
There are no syntax errors, but class Inner is not indented.
Yes, the indentation appears when pressing RET after {, but if we
then remove the spaces before class Inner and press RET again
after {, electric-indent corrects the indentation.
On one hand, this seems reasonable. On the other hand, shouldn=E2=80=99t th=
is
be handled by an external formatter? This is a minor issue and may
not require any changes.
> 3. The indentation is fixed once you type a valid statement, this is
> because tree-sitter needs something to generate a parse-tree. We
> can add some heuristics that gives a more intuitive indentation
> when the line is empty, eg, "if prev line is while and current line
> is empty, indent one level", etc. But that=E2=80=99s a more complicated
> feature and I=E2=80=99ll defer to Theo.
>
> 4.
> - Triple quote support in electric-pair-mode -> let=E2=80=99s open a sepa=
rate
> bug report for it and have electric-pair-mode maintainer take a
> look.
Should I classify this as a bug report? I didn=E2=80=99t notice any feature
request category in the bug tracker. This is a small improvement that
would add some convenience. Triple-quoted text blocks are not
exclusive to Java; many other languages use them as well.
> - In general, TAB in Emacs prog modes indent to a fixed point, rather
> than just inserting a tab.
I wasn=E2=80=99t aware of how this works. I briefly tested python-ts-mode a=
nd
noticed that TAB behaves more freely there.
>I added a indent rule such that aligns a
> line in a string block to the previous line, for the first line, it ind=
ents one level.
>
> 6. For the parameter indentation, I recently added
> c-ts-common-baseline-indent-rules that can handle it correctly. So
> if we remove the existing indent rule for the parameters and add
> c-ts-common-baseline-indent-rules at the end so the indentation
> falls back to it, the indentation would look like this:
>
> public class TextBlocks {
> public record StudentRecord(String firstName,
> String lastName,
> Long studentId,
> String email) {
>
> }
>
>
> public String filterData(@RequestParam(required =3D false) String nam=
e,
> @RequestParam(required =3D false) String nam=
e,
> @RequestParam(required =3D false) Integer age
> )
> }
>
> Seems fair? Theo, WDYT?
I tested it, and it works. But do you see how it behaves?
I=E2=80=99m not sure how to describe it correctly, but it feels a bit odd.
If issue #3 gets resolved, everything should look much better.
>> - Annotations (@Annotations)
> It seems to work fine? What=E2=80=99s the problem that you see?
That was my mistake. I didn=E2=80=99t check which face was being used=E2=80=
=94or
whether there was one at all. By default, java-mode uses
c-annotation-face,while java-ts-mode uses font-lock-constant-face.
One inherits from the other. I use the Modus theme, so something may
have changed there.I only noticed it because, without any additional
configuration, java-mode highlighted annotations by default.
Anyway, it=E2=80=99s not that important now.
>> - Diamond Brackets (<>)
> Same as above, what=E2=80=99s the desired behavior?
I just tested it with emacs -q and didn=E2=80=99t see any specific face for=
<>
in java-mode. I use the popular package rainbow-delimiters.el,
which does highlight <> in java-mode, but it hasn=E2=80=99t been updated in
a while and doesn=E2=80=99t work with java-ts-mode.Currently, java-ts-mode
applies font-lock-operator-face to <>, =3D, ->, &&, and possibly other
symbols.That doesn=E2=80=99t seem quite right=E2=80=94should all operators =
really be
highlighted this way? Some users might prefer extensive syntax
highlighting, but it feels excessive to me.
For reference, IntelliJ IDEA also doesn=E2=80=99t highlight <> by default.
It requires a third-party plugin for that. So I=E2=80=99m not sure whether
this should be added or not. If it is, that would be a nice improvement.
>> - Constants, Static Variables, Enum Variables should be highlighted with
>> distinct colors and optionally italic font
>
> For constants, they aren=E2=80=99t highlighted in constant face because r=
ules
> for =E2=80=98definition=E2=80=99 and =E2=80=98expression=E2=80=99 feature=
overrides them with
> variable-name face. We can fix this by either moving the =E2=80=98constan=
t=E2=80=99
> face after =E2=80=98definition=E2=80=99 and =E2=80=98expression=E2=80=99 =
feature, or remove the
> :override flag for =E2=80=98definition=E2=80=99 and =E2=80=98expression=
=E2=80=99 feature. Theo, any
> suggestions here?
That would be great to implement! I=E2=80=99m not sure how to show you exac=
tly
how it "should" look. Is it possible to attach images here?
Although, Theo might have IntelliJ IDEA CE installed, so he likely
already knows how it can look visually appealing.
>> - Unused Variables or Classes (Grayed Out)
>> - Unused variables, unused classes, etc., highlighted in gray. Not
> sure if this can be achieved
>
> Tree-sitter can=E2=80=99t do this. So the only option is to use eglot for=
it.
Thanks for the clarification! I=E2=80=99ll try to look into this.
----
By the way, I discovered something else today. In
java-ts-mode--keywords, the following keywords are missing:
boolean, byte, char, const, double, float,
goto, int, long, short, super, this, void, permits, var, when, yield, _.
According to the Java Language Specification
https://docs.oracle.com/javase/specs/jls/se23/html/jls-3.html#jls-3.9,
the keyword @interface should be removed since annotations are already
handled separately, and interface is already in the list.
> Finally, some suggestions on communication. As you said on reddit,
> you=E2=80=99re not a native English speaker, so I can=E2=80=99t blame you=
, but some
> minor changes to wording can make your message sound a lot kinder :)
> For example, short and imperative sentences like "you understand?"
> sounds harsh and condescending; OTOH something like "I hope you can
> understand/get that..." is a lot better. As a rule of thumb, the less
> certain and the longer your expression is, the softer it sounds ;-)
>
> Yuan
Yes, it is true that English is not my native language. However, upon
reviewing my messages,I understand that in certain instances, I was not
sufficiently polite. I will make an effort to improve this.
I regret that this occurred.
bug-gnu-emacs@HIDDEN:bug#75154; Package emacs.
Full text available.
Received: (at 75154) by debbugs.gnu.org; 1 Mar 2025 12:06:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 01 07:06:31 2025
Received: from localhost ([127.0.0.1]:34667 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1toLbv-0006Cj-RU
for submit <at> debbugs.gnu.org; Sat, 01 Mar 2025 07:06:31 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:37404)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1toLbq-0006Br-2Z
for 75154 <at> debbugs.gnu.org; Sat, 01 Mar 2025 07:06:25 -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 1toLbk-0005Ao-8E; Sat, 01 Mar 2025 07:06:16 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
Date; bh=pFtf/9YLFb2RUxCdPKEO16MqvgFxprowANxUsRDU6F4=; b=UbPe9d1ugeeIvAUJIaYI
kQO9gPK3uij3Ovg+QAuYeGArXn/oXrXc26Q7fT7hzxmWwexoPwV89xNvCTSQfbVSn9zmUctJHUGLf
UeybkPyYHKfHcNKIqVG5uApdemiePBmSLnLTGUcT5F4vUWlev2C5rMMIUQcNqzKLS3rAOQSyWFCKg
2w4Y3oWb9VU7CLyG9ql2ZXXAnHNPWWdFpC2RuWtvTrOnycGPoduT2LD6aAW0mHOjt3CnNNSQLVSxj
ZIq4W0c48N7eRthfFbtmS12sRqK8u0LDSDaEQTITRgj3Q/R70DSgFRPnPAY686dV92tW0l3/yHskh
d1KFx/GgcmPn/Q==;
Date: Sat, 01 Mar 2025 14:06:13 +0200
Message-Id: <86v7stoszu.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Yuan Fu <casouri@HIDDEN>
In-Reply-To: <05BB2FA6-8280-43CB-80A8-AC2A9F07F196@HIDDEN> (message from
Yuan Fu on Thu, 13 Feb 2025 22:24:06 -0800)
Subject: Re: bug#75154: 31.0.50; java-ts-mode. Issues with Indentation
References: <87ttapdtre.fsf@void> <86pllcurry.fsf@HIDDEN>
<CADwFkmmEZ8bQE+eFRUUmyg8vTq802Yfon_RsNB87ugpGhdmOUQ@HIDDEN>
<87h66dv6r7.fsf@HIDDEN>
<87cyg7dod2.fsf@HIDDEN>
<05BB2FA6-8280-43CB-80A8-AC2A9F07F196@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 75154
Cc: 75154 <at> debbugs.gnu.org, theo@HIDDEN, stefankangas@HIDDEN,
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: -3.3 (---)
Ping! Can we make some further progress here?
> From: Yuan Fu <casouri@HIDDEN>
> Date: Thu, 13 Feb 2025 22:24:06 -0800
> Cc: Theodor Thornhill <theo@HIDDEN>,
> 75154 <at> debbugs.gnu.org,
> Eli Zaretskii <eliz@HIDDEN>,
> Stefan Kangas <stefankangas@HIDDEN>
>
> > On Jan 28, 2025, at 6:06 AM, Artem <snake05865@HIDDEN> wrote:
> >
> > Okay, you may personally disagree. But why not create a separate
> > setting tailored to your preferences? You seem to agree that IntelliJ IDEA
> > is currently the canonical editor for Java. Set 8 spaces as the default and
> > add an option to adjust it.
> >
> > Do I need to provide examples of major open-source projects that use 8 spaces?
> > For instance, Apache Tomcat:
> > https://github.com/apache/tomcat/blob/cd997770105ea960764c3d7844e13c0bbe8fd3c1/java/org/apache/juli/OneLineFormatter.java#L102
> > Or Red Hat Quarkus:
> > https://github.com/quarkusio/quarkus/blob/0e013fabfc14557e688b559f6edea43b8934406a/devtools/cli/src/main/java/io/quarkus/cli/CliPlugins.java#L37
> >
> > I think this is a very important matter. Personally,
> > it drives me crazy when the spacing is off.
> >
> >> 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 = customer
> >> |; // Point is now at |
> >>
> >> }
> >> }
> >> ```
> >>
> >> Now we have a valid parse tree, indented correctly, and can continue
> >> chaining. I agree that this very much is a hack.
> >
> > Yes, it does look unnatural. And you know, there’s a similar issue in bash-ts-mode.
> > I can’t show the exact code snippet right now, but the behavior is essentially the same.
> > You press RET, the cursor ends up in the wrong position, then press RET again,
> > and the code block jumps to where it’s supposed to be.
> > Where’s the error? Is it a problem with the mode’s implementation
> > or a bug in Tree-sitter itself? Or did everyone just borrow logic from
> > each other, and now this indentation behavior has spread to other modes?
> >
> >>
> >>> Moreover, the current indentation is hardcoded and doesn’t 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 = 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 = 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();
> >>> }
> >>> }
> >
> > I’m not sure. Maybe I can create a new bug report? But honestly,
> > I don’t understand the point. A new report just to track the resolution
> > of some minor issue that annoys you and that you consider more important than others?
> >
> >>>
> >>> 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? 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.
> >
> > Yes, I’ve already figured that out, thank you. But what does it give me? Am I supposed
> > to just live with it? By the way, I tried disabling electric-indent-mode, but then indentation
> > stopped working entirely. I briefly went through the documentation to understand what’s going on,
> > and from what I gathered, this mode uses various backends, including Tree-sitter now.
> >
> > I could be wrong, but it seems like electric-indent-mode needs a review and a rethinking
> > of how it should work, considering Tree-sitter is being actively used.
> >
> > And the extra “magic” performed by electric-indent-mode might have been relevant a long
> > time ago, or maybe it still is in some cases. But for Java/C/C++, I don’t see why
> > it’s necessary. It’s just annoying and gets in the way.
> >
> >>> 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 incorrectly 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(){
> >> }
> >>
> >> }
> >> }
> >> ```
> >>
> >> Indentation at column 8 is expected here, IMO. I'm not sure we should
> >> try to work around clearly "incorrectly" indented code.
> >
> > In my understanding, and in IntelliJ IDEA’s, it should work so that
> > it doesn’t matter what syntactic construct, method, or anything else is far
> > behind—several levels above, to be exact. Tree-sitter should only care
> > about what’s one step behind you. It shouldn’t matter to you that the Inner
> > class is misplaced. Your method foo() should focus on where it belongs, even
> > if the Inner class has incorrect indentation. This isn’t a hack. It feels
> > natural—just follow what’s next to you.
> > Right now, it’s just a tightly coupled construct where breaking one
> > thing breaks another—or everything altogether.
> >
> >>
> >>>
> >>> 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
> >>> """));
> >>> }
> >>
> >> This isn't valid java is it? I changed it to
> >>
> >
> > Yes, this is invalid code. Again, this touches on how indentation works.
> > The machine and the code should think like me:
> > "You see I’ve placed triple quotes? You see there’s a method earlier?
> > Guess what I’m about to write? Of course, it’s going to be a TEXT BLOCK! Bingo!"
> > There’s nothing else I could possibly write there.
> >
> >> ```
> >> public class TextBlocks {
> >> public void foo() {
> >> System.out.println(ctx.fetch("""
> >> SELECT table_schema, count(*)
> >> FROM information_schema.tables
> >> """));
> >>
> >> }
> >> }
> >> ```
> >
> > Even if I write this code correctly, I still don't have the proper indentation.
> > Did you configure anything additional on your end? Out of the box, this doesn't work for me
> >
> > public class TextBlocks {
> > void foo() {
> > System.out.println(ctx.fetch(""" <-- 1. press RET
> > | <-- and you will be here (Actual)
> > | <-- Expected
> > """));
> > }
> > }
> >
> > java-mode, unlike java-ts-mode, is a bit smarter in this regard - the indentation is at least
> > somewhat recognized, but it still ends up in the wrong place. Manual adjustment of rules is required.
> >
> >> I usually indent stuff like this marking the region then using C-x i
> >> then <left> or <right>
> > What is C-x i? For me it's insert-file.
> >>
> >>> - New SQL expressions should be sticky
> >> What do you mean here? Align the newlines to the previous line?
> >
> > I've already forgotten what I meant. But yes, sticky means aligning the new line according
> > to the previous line. I think I saw this somewhere or maybe
> > I'm confusing it with Stream API method chains.
> >
> >>> 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
> >>
> >
> > Looks like I said too much here. I apologize. Yes, this works correctly.
> > For example, such code will make proper indentation
> > String sql = "SELECT u.id, u.name, u.email, COUNT(o.id) AS order_count " +
> > "FROM users u " +
> > "LEFT JOIN orders o ON u.id = o.user_id " +
> >
> >>> 6) Multiple Parameters in Methods
> >>> Example 1
> >>> public record StudentRecord(
> >>> String firstName,
> >>> String lastName,
> >>> Long studentId,
> >>> String email)
> >>
> >> What is wrong here?
> >
> > There's nothing broken in the code above. But in java-ts-mode it looks like this:
> >
> > public record StudentRecord(
> > String a,
> > String b, <--Actual (BAD)
> > String b <--Expected (Good)
> > )
> >
> >>> Example 2
> >>> public String filterData(@RequestParam(required = false) String name,
> >>> @RequestParam(required = false) String name,
> >>> @RequestParam(required = false) Integer age
> >>> )
> >>> java-ts-mode fails to handle these cases correctly.
> >>>
> >>
> >> How so?
> > Current behavior in java-ts-mode:
> > public String filterData(@RequestParam(required = false) String name,
> > @RequestParam(required = false) String name, <--Actual
> > @RequestParam(required = false) <--Expected
> > )
> >
> > You understand, I can't even press TAB to move this over?
> >
> >>> 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?
> >
> > These might be my personal wishes. But didn't some of this work out of the box in java-mode?
> > Am I right about this? Why did this disappear in java-ts-mode?
> > Actually, I wouldn't worry about this if I could simply press M-x customize and select
> > the needed colors. But... For some reason it's not that simple. In general,
> > custom color highlighting setup isn't very oriented towards people without Elisp knowledge.
> > Doesn't Emacs philosophy assume that many settings should be done this way
> > and all of this is then saved in custom.el?
> >
> >>> - 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 somewhat 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 ="HELLO";
> >>>
> >>> public static void main(String[] args) {
> >>> int i = 0; <-- Flymake identifies as unused but looks unpolished.
> >>> 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.
> >
> > You know what I thought about? I thought that since treesitter
> > builds a syntax tree of the file, it should be able to know what
> > in this tree has no usage and isn't connected to anything.
> >
> >>> Overall:
> >>>
> >>> 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.
> >
> > What priority for each problem? For me, everything is priority.
> > Maybe for someone who understands Elisp well, some things might be less urgent.
> > Very very very many people don't write anything in the bug tracker.
> > Because many things can really look like the user just needs to open
> > the Emacs Lisp references manual and do it themselves, rather than asking someone to do it for them.
> >
> > Slightly off-topic....
> >
> > Actually, I realized long ago that many things in Emacs are made so that users are given
> > some sandbox and provided opportunities to play in it themselves and customize it to their taste.
> > But there aren't many things that are really polished and designed to just open and use.
> > I haven't tried many programming modes. But recently I discovered Racket-mode.
> > God, how neat, polished, well-thought-out this mode looks and requires almost no additional setup
> > from the user, and tons of documentation is written.
> > For Java, which is in the top 3 languages worldwide, there is NOTHING in Emacs.
> > More precisely, there was something and it's probably gathering dust somewhere deep in Emacs' depths,
> > something like JDEE or CEDET which 1-2 people use. And nobody talks about this now and nowhere
> > is it written about. You need to do some research work to understand what was relevant before
> > and what wasn't.
> > Do you understand that there isn't even a "run main" button?
> > This is funny and sad.
> >
> >> 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.
> >
> > That's cool. I want to be like you and be the only Java developer who works in Emacs,
> > but reality is quite different for now. There's so much! So much! That needs to be finished.
> > Well okay, I'm lying, not that much.
> > I think attaching transient.el + hydra.el + a couple dozen functions and this should
> > become almost indistinguishable from IDE and maybe even superior in some places.
> > But this still needs to be done...
> >
> >> 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.
> >>
> >>
> >> 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.
> >
> > As soon as there's some interested person who wants to do some refactoring
> > of everything that was previously done for JAVA in Emacs
> > and rewrites/writes/adapts it to new realities.
> > I'll be able to officially declare that Emacs will be the best editor/IDE for Java.
> > But for now, that person hasn't been born yet. Or maybe it all exists already,
> > but somewhere in personal repositories on GitHub or somewhere else,
> > but won't make it into the core of java-ts-mode.
> >
> > I know you're not the only one who writes Java in Emacs and remains productive.
> > But... I expressed my thoughts about the situation earlier.
> > And you understand these are thoughts of an ordinary person, not an Emacs hacker.
> > If you can do it, it doesn't mean that thousands of others can do exactly the same.
>
>
> Ok, I attached a patch-set, if you apply this patch-set on top of _latest master_, most of the fixable problems in this report should be fixed/improved. Now, let me reply each item:
>
> 1. In the patch I added java-ts-mode-method-chaining-indent-offset,
> defaults to 8
>
> 2. Set electric-indent-chars to nil so it doesn’t indent the current
> line when you press RET.
>
> 3. The indentation is fixed once you type a valid statement, this is
> because tree-sitter needs something to generate a parse-tree. We
> can add some heuristics that gives a more intuitive indentation
> when the line is empty, eg, "if prev line is while and current line
> is empty, indent one level", etc. But that’s a more complicated
> feature and I’ll defer to Theo.
>
> 4.
> - Triple quote support in electric-pair-mode -> let’s open a separate
> bug report for it and have electric-pair-mode maintainer take a
> look.
>
> - In general, TAB in Emacs prog modes indent to a fixed point, rather
> than just inserting a tab. I added a indent rule such that aligns a
> line in a string block to the previous line, for the first line, it indents one level.
>
> 5. That’s hard, if not impossible, for tree-sitter to do. When using a
> parser for highlight/indentation, you need provide a correct (or
> close to correct) source code for it to work right. That’s part of
> the trade-off comparing to regexp-based highlighting.
>
> 6. For the parameter indentation, I recently added
> c-ts-common-baseline-indent-rules that can handle it correctly. So
> if we remove the existing indent rule for the parameters and add
> c-ts-common-baseline-indent-rules at the end so the indentation
> falls back to it, the indentation would look like this:
>
> public class TextBlocks {
> public record StudentRecord(String firstName,
> String lastName,
> Long studentId,
> String email) {
>
> }
>
>
> public String filterData(@RequestParam(required = false) String name,
> @RequestParam(required = false) String name,
> @RequestParam(required = false) Integer age
> )
> }
>
> Seems fair? Theo, WDYT?
>
> > - Annotations (@Annotations)
> It seems to work fine? What’s the problem that you see?
>
> > - Diamond Brackets (<>)
> Same as above, what’s the desired behavior?
>
> > - Constants, Static Variables, Enum Variables should be highlighted with
> > distinct colors and optionally italic font
>
> For constants, they aren’t highlighted in constant face because rules
> for ‘definition’ and ‘expression’ feature overrides them with
> variable-name face. We can fix this by either moving the ‘constant’
> face after ‘definition’ and ‘expression’ feature, or remove the
> :override flag for ‘definition’ and ‘expression’ feature. Theo, any
> suggestions here?
>
> > - Unused Variables or Classes (Grayed Out)
> > - Unused variables, unused classes, etc., highlighted in gray. Not
> sure if this can be achieved
>
> Tree-sitter can’t do this. So the only option is to use eglot for it.
>
> Finally, some suggestions on communication. As you said on reddit,
> you’re not a native English speaker, so I can’t blame you, but some
> minor changes to wording can make your message sound a lot kinder :)
> For example, short and imperative sentences like "you understand?"
> sounds harsh and condescending; OTOH something like "I hope you can
> understand/get that..." is a lot better. As a rule of thumb, the less
> certain and the longer your expression is, the softer it sounds ;-)
>
> Yuan
bug-gnu-emacs@HIDDEN:bug#75154; Package emacs.
Full text available.
Received: (at 75154) by debbugs.gnu.org; 14 Feb 2025 06:24:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 14 01:24:39 2025
Received: from localhost ([127.0.0.1]:46684 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tip7p-00007b-MS
for submit <at> debbugs.gnu.org; Fri, 14 Feb 2025 01:24:38 -0500
Received: from mail-pl1-x629.google.com ([2607:f8b0:4864:20::629]:52249)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <casouri@HIDDEN>) id 1tip7h-00007C-Lf
for 75154 <at> debbugs.gnu.org; Fri, 14 Feb 2025 01:24:31 -0500
Received: by mail-pl1-x629.google.com with SMTP id
d9443c01a7336-21f49bd087cso25515815ad.0
for <75154 <at> debbugs.gnu.org>; Thu, 13 Feb 2025 22:24:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1739514260; x=1740119060; darn=debbugs.gnu.org;
h=references:to:cc:in-reply-to:date:subject:mime-version:message-id
:from:from:to:cc:subject:date:message-id:reply-to;
bh=a5LJyZarI6YUllx6tAhArOb+bbefYGBkkIK2aLDJLoA=;
b=Wsbj1P5ngC/hmLIUPbPttK46KhNZtni9N2JP8fpyQtbadFBOlGL59DSSRwPXTvI/st
tEdom7+zp21spr3YquuplymEG7VD7ABYmncLt3C9FTFofGhywwJi4DbHZBPnNmS2bjXV
NyuMJjtNjISxe8iJpHoesx7mTlB09pKV2tEev+Ll/sJXWkz5GAcEhSWy5toT65wW4Rbq
HOimcVzE5NxOpEprjwyVTs4DdCG8TtvYjPYmYk00SXxOd7eZcupiDJk/KmPZPZPCORg1
NOK3KmFO4lkhISYA0PhY/CTgQ/7YsNT+xHxyXL5VanCLDzYgHf3kFG0e2Ctr8IBYvSN1
tA7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1739514260; x=1740119060;
h=references:to:cc:in-reply-to:date:subject:mime-version:message-id
:from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=a5LJyZarI6YUllx6tAhArOb+bbefYGBkkIK2aLDJLoA=;
b=Pzs1iRBypVxfei2KmL3Bre+jAc2yF7RAURffkvcg4UhxI2AP3nzknuHbm8bZYMmxOL
NHy1rOwX/G12pn66OFqgoQ3BImj71bGs5i1novr4pizgfjZBHzhbniJTMsRoCXXfEjPu
EOYialNu2F4Lq8th9RnIHVt/4Aljd8N1IzpgGTe/MtCKr5RUHmwDuiESZTYO9ylbHAiV
DcIaQRKKWzHDVmUOAZta9fz0PEhBnivfnB/6N20NERqQe8ZeYoOxoserjvty/AvA0/kF
dwURbw2mV3XUfGMinaHnW6bw+0v6jBjA5tklL80eTbucZkwCe1g59SRhje/XZmFXFi71
0q3Q==
X-Forwarded-Encrypted: i=1;
AJvYcCVljxwjW/3amZcRZr57KF0c54akzH1Rcv/QsKcrywQsAf2P8PrPnDjaBVU1aW5+zYRN+5PYEQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yx0I2JVgmEoTKLoDsrF6N/Y+mVDA4xTDrz50bJjaIfJNHWFnotN
IAMq/ERhH/78bp6LlLi0drVbj2ZnLLzbsiktnJnuPrsPI3jSiYJS
X-Gm-Gg: ASbGncuqqX0azM5BxA+DzYXdCM4FxhFCAdAYLSepC1ag8qfvbpxdlyrfukz6gIN0JpH
Jv4I1FdrFKyaZq10FkzC4XaDLX+MX9YfYnsBWRrAcZq2vd7R+eVUoqO4uU8MUL674PLJJLVL4/j
BYnK/nOyw6doMNf5EjthW8EhnGn+BFMncHADi1RYXdA344gAGRctK+xmgHPVC9N9U1NwYP4VpEd
OfcuKCPuK/FmMijzFiwGMmt/cUOCHnZp8MqiYZhPSLhmkISTXLpf/0KSb+NGlbS8fwLwPKh9fDV
dVQl/QKQ9faova6/he6f7WYsu3LhllnnwQ+nhJE=
X-Google-Smtp-Source: AGHT+IGc6aphmXyDssb2AuC9DMCM5I7QTxDacvx7keqGt/lHmZ99rgEfb9g2rg0zx8icmJxe6Bi25Q==
X-Received: by 2002:a17:903:947:b0:21c:fb6:7c3c with SMTP id
d9443c01a7336-220d1ed291cmr90972865ad.17.1739514259135;
Thu, 13 Feb 2025 22:24:19 -0800 (PST)
Received: from smtpclient.apple ([2601:646:8f81:6120:2cf8:c709:1052:521c])
by smtp.gmail.com with ESMTPSA id
d9443c01a7336-220d536b047sm22360845ad.101.2025.02.13.22.24.17
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Thu, 13 Feb 2025 22:24:18 -0800 (PST)
From: Yuan Fu <casouri@HIDDEN>
Message-Id: <05BB2FA6-8280-43CB-80A8-AC2A9F07F196@HIDDEN>
Content-Type: multipart/mixed;
boundary="Apple-Mail=_022B1C8E-3C16-4483-BA15-59767EA7529E"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
Subject: Re: bug#75154: 31.0.50; java-ts-mode. Issues with Indentation
Date: Thu, 13 Feb 2025 22:24:06 -0800
In-Reply-To: <87cyg7dod2.fsf@HIDDEN>
To: Artem <snake05865@HIDDEN>
References: <87ttapdtre.fsf@void> <86pllcurry.fsf@HIDDEN>
<CADwFkmmEZ8bQE+eFRUUmyg8vTq802Yfon_RsNB87ugpGhdmOUQ@HIDDEN>
<87h66dv6r7.fsf@HIDDEN>
<87cyg7dod2.fsf@HIDDEN>
X-Mailer: Apple Mail (2.3776.700.51)
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75154
Cc: 75154 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
Theodor Thornhill <theo@HIDDEN>, Stefan Kangas <stefankangas@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 (-)
--Apple-Mail=_022B1C8E-3C16-4483-BA15-59767EA7529E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
> On Jan 28, 2025, at 6:06=E2=80=AFAM, Artem <snake05865@HIDDEN> =
wrote:
>=20
> Okay, you may personally disagree. But why not create a separate
> setting tailored to your preferences? You seem to agree that IntelliJ =
IDEA
> is currently the canonical editor for Java. Set 8 spaces as the =
default and
> add an option to adjust it.
>=20
> Do I need to provide examples of major open-source projects that use 8 =
spaces?
> For instance, Apache Tomcat:
> =
https://github.com/apache/tomcat/blob/cd997770105ea960764c3d7844e13c0bbe8f=
d3c1/java/org/apache/juli/OneLineFormatter.java#L102
> Or Red Hat Quarkus:
> =
https://github.com/quarkusio/quarkus/blob/0e013fabfc14557e688b559f6edea43b=
8934406a/devtools/cli/src/main/java/io/quarkus/cli/CliPlugins.java#L37
>=20
> I think this is a very important matter. Personally,
> it drives me crazy when the spacing is off.
>=20
>> While this is probably catchable, the "workaround" I started using is =
to
>> end the statement with a semi, then RET:
>>=20
>> ```
>> class Foo {
>> void Foo() {
>> List<Customer> customers =3D customer
>> |; // Point is now at |
>>=20
>> }
>> }
>> ```
>>=20
>> Now we have a valid parse tree, indented correctly, and can continue
>> chaining. I agree that this very much is a hack.
>=20
> Yes, it does look unnatural. And you know, there=E2=80=99s a similar =
issue in bash-ts-mode.
> I can=E2=80=99t show the exact code snippet right now, but the =
behavior is essentially the same.
> You press RET, the cursor ends up in the wrong position, then press =
RET again,
> and the code block jumps to where it=E2=80=99s supposed to be.
> Where=E2=80=99s the error? Is it a problem with the mode=E2=80=99s =
implementation
> or a bug in Tree-sitter itself? Or did everyone just borrow logic from
> each other, and now this indentation behavior has spread to other =
modes?
>=20
>>=20
>>> 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();
>>> })
>>=20
>> 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?
>>=20
>>> .map()
>>> .collect();
>>> }
>>> }
>=20
> I=E2=80=99m not sure. Maybe I can create a new bug report? But =
honestly,
> I don=E2=80=99t understand the point. A new report just to track the =
resolution
> of some minor issue that annoys you and that you consider more =
important than others?
>=20
>>>=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
>>> 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.
>>>=20
>>=20
>> This is due to electric indent. You could disable it yourself in your
>> config or just live with it.
>=20
> Yes, I=E2=80=99ve already figured that out, thank you. But what does =
it give me? Am I supposed
> to just live with it? By the way, I tried disabling =
electric-indent-mode, but then indentation
> stopped working entirely. I briefly went through the documentation to =
understand what=E2=80=99s going on,
> and from what I gathered, this mode uses various backends, including =
Tree-sitter now.
>=20
> I could be wrong, but it seems like electric-indent-mode needs a =
review and a rethinking
> of how it should work, considering Tree-sitter is being actively used.
>=20
> And the extra =E2=80=9Cmagic=E2=80=9D performed by =
electric-indent-mode might have been relevant a long
> time ago, or maybe it still is in some cases. But for Java/C/C++, I =
don=E2=80=99t see why
> it=E2=80=99s necessary. It=E2=80=99s just annoying and gets in the =
way.
>=20
>>> 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 incorrectly indented.
>>>=20
>>=20
>> 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
>> Indentation at column 8 is expected here, IMO. I'm not sure we should
>> try to work around clearly "incorrectly" indented code.
>=20
> In my understanding, and in IntelliJ IDEA=E2=80=99s, it should work so =
that
> it doesn=E2=80=99t matter what syntactic construct, method, or =
anything else is far
> behind=E2=80=94several levels above, to be exact. Tree-sitter should =
only care
> about what=E2=80=99s one step behind you. It shouldn=E2=80=99t matter =
to you that the Inner
> class is misplaced. Your method foo() should focus on where it =
belongs, even
> if the Inner class has incorrect indentation. This isn=E2=80=99t a =
hack. It feels
> natural=E2=80=94just follow what=E2=80=99s next to you. =20
> Right now, it=E2=80=99s just a tightly coupled construct where =
breaking one
> thing breaks another=E2=80=94or everything altogether. =20
>=20
>>=20
>>>=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
>>> """));
>>> }
>>=20
>> This isn't valid java is it? I changed it to=20
>>=20
>=20
> Yes, this is invalid code. Again, this touches on how indentation =
works.
> The machine and the code should think like me:
> "You see I=E2=80=99ve placed triple quotes? You see there=E2=80=99s a =
method earlier?
> Guess what I=E2=80=99m about to write? Of course, it=E2=80=99s going =
to be a TEXT BLOCK! Bingo!"
> There=E2=80=99s nothing else I could possibly write there.
>=20
>> ```
>> public class TextBlocks {
>> public void foo() {
>> System.out.println(ctx.fetch("""
>> SELECT table_schema, count(*)
>> FROM information_schema.tables
>> """));
>>=20
>> } =20
>> }
>> ```
>=20
> Even if I write this code correctly, I still don't have the proper =
indentation.
> Did you configure anything additional on your end? Out of the box, =
this doesn't work for me
>=20
> public class TextBlocks {
> void foo() {
> System.out.println(ctx.fetch(""" <-- 1. press RET=20
> | <-- and you will be here (Actual)=20
> | <-- Expected
> """));
> }
> }
>=20
> java-mode, unlike java-ts-mode, is a bit smarter in this regard - the =
indentation is at least
> somewhat recognized, but it still ends up in the wrong place. Manual =
adjustment of rules is required.
>=20
>> I usually indent stuff like this marking the region then using C-x i
>> then <left> or <right>
> What is C-x i? For me it's insert-file.
>>=20
>>> - New SQL expressions should be sticky
>> What do you mean here? Align the newlines to the previous line?
>=20
> I've already forgotten what I meant. But yes, sticky means aligning =
the new line according
> to the previous line. I think I saw this somewhere or maybe
> I'm confusing it with Stream API method chains.
>=20
>>> It seems such multiline strings also do not work well, for example:
>>> "'The time has come,' the Walrus said,\n" +
>>=20
>> Not sure I understand what you mean here
>>=20
>=20
> Looks like I said too much here. I apologize. Yes, this works =
correctly.
> For example, such code will make proper indentation
> String sql =3D "SELECT u.id, u.name, u.email, COUNT(o.id) AS =
order_count " +
> "FROM users u " +
> "LEFT JOIN orders o ON u.id =3D o.user_id " +
>=20
>>> 6) Multiple Parameters in Methods
>>> Example 1
>>> public record StudentRecord(
>>> String firstName,=20
>>> String lastName,=20
>>> Long studentId,=20
>>> String email)
>>=20
>> What is wrong here?
>=20
> There's nothing broken in the code above. But in java-ts-mode it looks =
like this:
>=20
> public record StudentRecord(
> String a,
> String b, <--Actual (BAD)
> String b <--Expected (Good) =20
> )
>=20
>>> 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.
>>>=20
>>=20
>> How so?
> Current behavior in java-ts-mode:
> public String filterData(@RequestParam(required =3D false) String =
name,
> @RequestParam(required =3D false) String name, <--Actual
> @RequestParam(required =3D false) =
<--Expected
> )
>=20
> You understand, I can't even press TAB to move this over?
>=20
>>> 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)
>>=20
>> 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?
>=20
> These might be my personal wishes. But didn't some of this work out of =
the box in java-mode?
> Am I right about this? Why did this disappear in java-ts-mode?
> Actually, I wouldn't worry about this if I could simply press M-x =
customize and select
> the needed colors. But... For some reason it's not that simple. In =
general,
> custom color highlighting setup isn't very oriented towards people =
without Elisp knowledge.
> Doesn't Emacs philosophy assume that many settings should be done this =
way
> and all of this is then saved in custom.el?
>=20
>>> - 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 somewhat clunky manner.
>>>=20
>>=20
>> 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.
>>=20
>>> 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 =
unpolished.=20
>>> System.out.println(HELLO);
>>> }
>>> }
>>>=20
>>=20
>> This isn't treesit related, but could be a report for flymake
>> maintainers. We need to get the information from the server, though.
>=20
> You know what I thought about? I thought that since treesitter
> builds a syntax tree of the file, it should be able to know what
> in this tree has no usage and isn't connected to anything.
>=20
>>> Overall:
>>>=20
>>> I may have missed some aspects, but as it stands, Emacs is not
>>> comfortable for Java development with these issues.
>>>=20
>>=20
>> 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.
>=20
> What priority for each problem? For me, everything is priority.
> Maybe for someone who understands Elisp well, some things might be =
less urgent.
> Very very very many people don't write anything in the bug tracker.
> Because many things can really look like the user just needs to open
> the Emacs Lisp references manual and do it themselves, rather than =
asking someone to do it for them.
>=20
> Slightly off-topic....
>=20
> Actually, I realized long ago that many things in Emacs are made so =
that users are given
> some sandbox and provided opportunities to play in it themselves and =
customize it to their taste.
> But there aren't many things that are really polished and designed to =
just open and use.
> I haven't tried many programming modes. But recently I discovered =
Racket-mode.
> God, how neat, polished, well-thought-out this mode looks and requires =
almost no additional setup
> from the user, and tons of documentation is written.
> For Java, which is in the top 3 languages worldwide, there is NOTHING =
in Emacs.
> More precisely, there was something and it's probably gathering dust =
somewhere deep in Emacs' depths,
> something like JDEE or CEDET which 1-2 people use. And nobody talks =
about this now and nowhere
> is it written about. You need to do some research work to understand =
what was relevant before
> and what wasn't.
> Do you understand that there isn't even a "run main" button?
> This is funny and sad.
>=20
>> 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.
>=20
> That's cool. I want to be like you and be the only Java developer who =
works in Emacs,
> but reality is quite different for now. There's so much! So much! That =
needs to be finished.
> Well okay, I'm lying, not that much.
> I think attaching transient.el + hydra.el + a couple dozen functions =
and this should
> become almost indistinguishable from IDE and maybe even superior in =
some places.
> But this still needs to be done...
>=20
>> 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.
>>=20
>>=20
>> 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.
>=20
> As soon as there's some interested person who wants to do some =
refactoring
> of everything that was previously done for JAVA in Emacs
> and rewrites/writes/adapts it to new realities.
> I'll be able to officially declare that Emacs will be the best =
editor/IDE for Java.
> But for now, that person hasn't been born yet. Or maybe it all exists =
already,
> but somewhere in personal repositories on GitHub or somewhere else,
> but won't make it into the core of java-ts-mode.
>=20
> I know you're not the only one who writes Java in Emacs and remains =
productive.
> But... I expressed my thoughts about the situation earlier.
> And you understand these are thoughts of an ordinary person, not an =
Emacs hacker.
> If you can do it, it doesn't mean that thousands of others can do =
exactly the same.
Ok, I attached a patch-set, if you apply this patch-set on top of =
_latest master_, most of the fixable problems in this report should be =
fixed/improved. Now, let me reply each item:
1. In the patch I added java-ts-mode-method-chaining-indent-offset,
defaults to 8
2. Set electric-indent-chars to nil so it doesn=E2=80=99t indent the =
current
line when you press RET.
3. The indentation is fixed once you type a valid statement, this is
because tree-sitter needs something to generate a parse-tree. We
can add some heuristics that gives a more intuitive indentation
when the line is empty, eg, "if prev line is while and current line
is empty, indent one level", etc. But that=E2=80=99s a more =
complicated
feature and I=E2=80=99ll defer to Theo.
4.
- Triple quote support in electric-pair-mode -> let=E2=80=99s open a =
separate
bug report for it and have electric-pair-mode maintainer take a
look.
- In general, TAB in Emacs prog modes indent to a fixed point, rather
than just inserting a tab. I added a indent rule such that aligns a
line in a string block to the previous line, for the first line, it =
indents one level.
5. That=E2=80=99s hard, if not impossible, for tree-sitter to do. When =
using a
parser for highlight/indentation, you need provide a correct (or
close to correct) source code for it to work right. That=E2=80=99s =
part of
the trade-off comparing to regexp-based highlighting.
6. For the parameter indentation, I recently added
c-ts-common-baseline-indent-rules that can handle it correctly. So
if we remove the existing indent rule for the parameters and add
c-ts-common-baseline-indent-rules at the end so the indentation
falls back to it, the indentation would look like this:
public class TextBlocks {
public record StudentRecord(String firstName,
String lastName,
Long studentId,
String email) {
}
public String filterData(@RequestParam(required =3D false) String =
name,
@RequestParam(required =3D false) String =
name,
@RequestParam(required =3D false) Integer =
age
)
}
Seems fair? Theo, WDYT?
> - Annotations (@Annotations)
It seems to work fine? What=E2=80=99s the problem that you see?
> - Diamond Brackets (<>)
Same as above, what=E2=80=99s the desired behavior?
> - Constants, Static Variables, Enum Variables should be highlighted =
with
> distinct colors and optionally italic font
For constants, they aren=E2=80=99t highlighted in constant face because =
rules
for =E2=80=98definition=E2=80=99 and =E2=80=98expression=E2=80=99 =
feature overrides them with
variable-name face. We can fix this by either moving the =E2=80=98constant=
=E2=80=99
face after =E2=80=98definition=E2=80=99 and =E2=80=98expression=E2=80=99 =
feature, or remove the
:override flag for =E2=80=98definition=E2=80=99 and =E2=80=98expression=E2=
=80=99 feature. Theo, any
suggestions here?
> - Unused Variables or Classes (Grayed Out)
> - Unused variables, unused classes, etc., highlighted in gray. Not
sure if this can be achieved
Tree-sitter can=E2=80=99t do this. So the only option is to use eglot =
for it.
Finally, some suggestions on communication. As you said on reddit,
you=E2=80=99re not a native English speaker, so I can=E2=80=99t blame =
you, but some
minor changes to wording can make your message sound a lot kinder :)
For example, short and imperative sentences like "you understand?"
sounds harsh and condescending; OTOH something like "I hope you can
understand/get that..." is a lot better. As a rule of thumb, the less
certain and the longer your expression is, the softer it sounds ;-)
Yuan
--Apple-Mail=_022B1C8E-3C16-4483-BA15-59767EA7529E
Content-Disposition: attachment;
filename=java-ts-mode-updates.patch
Content-Type: application/octet-stream;
x-unix-mode=0644;
name="java-ts-mode-updates.patch"
Content-Transfer-Encoding: quoted-printable
=46rom=2049cade63907e63bdc171002f30b798ae35f609eb=20Mon=20Sep=2017=20=
00:00:00=202001=0AFrom:=20Yuan=20Fu=20<casouri@HIDDEN>=0ADate:=20Thu,=20=
13=20Feb=202025=2007:57:19=20-0800=0ASubject:=20[PATCH=201/3]=20Add=20=
java-ts-mode-method-chaining-indent-offset=0A=20(bug#75154)=0A=0ADefault=20=
method=20chaining=20to=20indent=208=20spaces.=0A=0A*=20=
lisp/progmodes/java-ts-mode.el:=0A=
(java-ts-mode-method-chaining-indent-offset):=20New=20custom=20option.=0A=
(java-ts-mode--indent-rules):=20Use=0A=
java-ts-mode-method-chaining-indent-offset.=0A---=0A=20=
lisp/progmodes/java-ts-mode.el=20|=209=20++++++++-=0A=201=20file=20=
changed,=208=20insertions(+),=201=20deletion(-)=0A=0Adiff=20--git=20=
a/lisp/progmodes/java-ts-mode.el=20b/lisp/progmodes/java-ts-mode.el=0A=
index=20cbf5db24afd..2bd285dd068=20100644=0A---=20=
a/lisp/progmodes/java-ts-mode.el=0A+++=20=
b/lisp/progmodes/java-ts-mode.el=0A@@=20-50,6=20+50,13=20@@=20=
java-ts-mode-indent-offset=0A=20=20=20:safe=20'integerp=0A=20=20=20=
:group=20'java)=0A=20=0A+(defcustom=20=
java-ts-mode-method-chaining-indent-offset=208=0A+=20=20"Indent=20offset=20=
for=20method=20chaining=20in=20`java-ts-mode'."=0A+=20=20:version=20=
"31.1"=0A+=20=20:type=20'integer=0A+=20=20:safe=20'integerp=0A+=20=20=
:group=20'java)=0A+=0A=20(defcustom=20java-ts-mode-enable-doxygen=20nil=0A=
=20=20=20"Enable=20doxygen=20syntax=20highlighting.=0A=20If=20Non-nil,=20=
enable=20doxygen=20based=20font=20lock=20for=20comment=20blocks.=0A@@=20=
-121,7=20+128,7=20@@=20java-ts-mode--indent-rules=0A=20=20=20=20=20=20=
((parent-is=20"variable_declarator")=20parent-bol=20=
java-ts-mode-indent-offset)=0A=20=20=20=20=20=20((match=20">"=20=
"type_arguments")=20parent-bol=200)=0A=20=20=20=20=20=20((parent-is=20=
"type_arguments")=20parent-bol=20java-ts-mode-indent-offset)=0A-=20=20=20=
=20=20((parent-is=20"method_invocation")=20parent-bol=20=
java-ts-mode-indent-offset)=0A+=20=20=20=20=20((parent-is=20=
"method_invocation")=20parent-bol=20=
java-ts-mode-method-chaining-indent-offset)=0A=20=20=20=20=20=20=
((parent-is=20"switch_rule")=20parent-bol=20java-ts-mode-indent-offset)=0A=
=20=20=20=20=20=20((parent-is=20"switch_label")=20parent-bol=20=
java-ts-mode-indent-offset)=0A=20=20=20=20=20=20((parent-is=20=
"ternary_expression")=20parent-bol=20java-ts-mode-indent-offset)=0A--=20=0A=
2.39.5=20(Apple=20Git-151)=0A=0A=0A=46rom=20=
ab2fce8ea711e4ac1afc6f989d50aa8d8f7f2bf4=20Mon=20Sep=2017=2000:00:00=20=
2001=0AFrom:=20Yuan=20Fu=20<casouri@HIDDEN>=0ADate:=20Thu,=2013=20Feb=20=
2025=2018:23:43=20-0800=0ASubject:=20[PATCH=202/3]=20Add=20indentation=20=
for=20multi-line=20string=20in=20java-ts-mode=0A=20(bug#75154)=0A=0A*=20=
lisp/progmodes/java-ts-mode.el:=0A=
(java-ts-mode--first-line-on-multi-line-string):=20New=20function.=0A=
(java-ts-mode--indent-rules):=20Add=20rules.=0A---=0A=20=
lisp/progmodes/java-ts-mode.el=20|=2012=20++++++++++++=0A=201=20file=20=
changed,=2012=20insertions(+)=0A=0Adiff=20--git=20=
a/lisp/progmodes/java-ts-mode.el=20b/lisp/progmodes/java-ts-mode.el=0A=
index=202bd285dd068..c2c9cc37182=20100644=0A---=20=
a/lisp/progmodes/java-ts-mode.el=0A+++=20=
b/lisp/progmodes/java-ts-mode.el=0A@@=20-91,6=20+91,14=20@@=20=
java-ts-mode--syntax-table=0A=20=20=20=20=20table)=0A=20=20=20"Syntax=20=
table=20for=20`java-ts-mode'.")=0A=20=0A+(defun=20=
java-ts-mode--first-line-on-multi-line-string=20(_node=20parent=20bol=20=
&rest=20_)=0A+=20=20"Simple-indent=20matcher=20for=20the=20first=20line=20=
in=20a=20multi-line=20string=20block.=0A+PARENT=20and=20BOL=20are=20the=20=
as=20in=20other=20matchers."=0A+=20=20(and=20(treesit-node-match-p=20=
parent=20"multiline_string_fragment")=0A+=20=20=20=20=20=20=20=
(save-excursion=0A+=20=20=20=20=20=20=20=20=20;;=20Less=20than=202=20=
newlines=20between=20point=20and=20string=20start.=0A+=20=20=20=20=20=20=20=
=20=20(not=20(search-backward=20"\n"=20(treesit-node-start=20parent)=20t=20=
2)))))=0A+=0A=20(defvar=20java-ts-mode--indent-rules=0A=20=20=20`((java=0A=
=20=20=20=20=20=20((parent-is=20"program")=20column-0=200)=0A@@=20-108,6=20=
+116,10=20@@=20java-ts-mode--indent-rules=0A=20=20=20=20=20=20((and=20=
(parent-is=20"comment")=20c-ts-common-looking-at-star)=0A=20=20=20=20=20=20=
=20c-ts-common-comment-start-after-first-star=20-1)=0A=20=20=20=20=20=20=
((parent-is=20"comment")=20prev-adaptive-prefix=200)=0A+=20=20=20=20=20=
(java-ts-mode--first-line-on-multi-line-string=20parent-bol=0A+=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
java-ts-mode-indent-offset)=0A+=20=20=20=20=20((parent-is=20=
"multiline_string_fragment")=20prev-adaptive-prefix=200)=0A+=20=20=20=20=20=
((match=20"\"\"\""=20"string_literal"=20nil=201)=20prev-adaptive-prefix=20=
0)=0A=20=20=20=20=20=20((parent-is=20"text_block")=20no-indent)=0A=20=20=20=
=20=20=20((parent-is=20"class_body")=20column-0=20=
c-ts-common-statement-offset)=0A=20=20=20=20=20=20((parent-is=20=
"array_initializer")=20parent-bol=20java-ts-mode-indent-offset)=0A--=20=0A=
2.39.5=20(Apple=20Git-151)=0A=0A=0A=46rom=20=
fc5ea24ff66d73a124b72014d3dda49fe5c2c5ff=20Mon=20Sep=2017=2000:00:00=20=
2001=0AFrom:=20Yuan=20Fu=20<casouri@HIDDEN>=0ADate:=20Thu,=2013=20Feb=20=
2025=2018:24:41=20-0800=0ASubject:=20[PATCH=203/3]=20Use=20c-ts-common=20=
baseline=20rule=20in=20java-ts-mode=20(bug#75154)=0A=0AUse=20it=20for=20=
function=20parameters.=0A=0A*=20lisp/progmodes/java-ts-mode.el:=0A=
(java-ts-mode--standalone-predicate):=20New=20function.=0A=
(java-ts-mode--indent-rules):=20Comment=20out=20rules=20for=20function=0A=
parameters=20and=20statements,=20and=20add=0A=
c-ts-common-baseline-indent-rule=20as=20fallback.=0A(java-ts-mode):=20=
Setup.=0A*=20test/lisp/progmodes/java-ts-mode-resources/indent.erts:=0A=
New=20test.=0A---=0A=20lisp/progmodes/java-ts-mode.el=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20|=2021=20++++++++++++--=0A=20=
.../java-ts-mode-resources/indent.erts=20=20=20=20=20=20=20=20|=2028=20=
+++++++++++++++++++=0A=202=20files=20changed,=2046=20insertions(+),=203=20=
deletions(-)=0A=0Adiff=20--git=20a/lisp/progmodes/java-ts-mode.el=20=
b/lisp/progmodes/java-ts-mode.el=0Aindex=20c2c9cc37182..e1686f29c41=20=
100644=0A---=20a/lisp/progmodes/java-ts-mode.el=0A+++=20=
b/lisp/progmodes/java-ts-mode.el=0A@@=20-91,6=20+91,17=20@@=20=
java-ts-mode--syntax-table=0A=20=20=20=20=20table)=0A=20=20=20"Syntax=20=
table=20for=20`java-ts-mode'.")=0A=20=0A+(defun=20=
java-ts-mode--standalone-predicate=20(node)=0A+=20=20"Java's=20=
standalone=20predicate.=0A+Return=20t=20if=20NODE=20is=20on=20the=20=
start=20of=20a=20line."=0A+=20=20(save-excursion=0A+=20=20=20=20=
(goto-char=20(treesit-node-start=20node))=0A+=20=20=20=20(if=20=
(looking-back=20(rx=20bol=20(*=20whitespace)=20(?=20"."))=20(pos-bol))=0A=
+=20=20=20=20=20=20=20=20t=0A+=20=20=20=20=20=20(back-to-indentation)=0A=
+=20=20=20=20=20=20(when=20(eq=20(char-after)=20?.)=0A+=20=20=20=20=20=20=
=20=20(point)))))=0A+=0A=20(defun=20=
java-ts-mode--first-line-on-multi-line-string=20(_node=20parent=20bol=20=
&rest=20_)=0A=20=20=20"Simple-indent=20matcher=20for=20the=20first=20=
line=20in=20a=20multi-line=20string=20block.=0A=20PARENT=20and=20BOL=20=
are=20the=20as=20in=20other=20matchers."=0A@@=20-154,8=20+165,8=20@@=20=
java-ts-mode--indent-rules=0A=20=20=20=20=20=20((parent-is=20=
"argument_list")=20parent-bol=20java-ts-mode-indent-offset)=0A=20=20=20=20=
=20=20((parent-is=20"annotation_argument_list")=20parent-bol=20=
java-ts-mode-indent-offset)=0A=20=20=20=20=20=20((parent-is=20=
"modifiers")=20parent-bol=200)=0A-=20=20=20=20=20((parent-is=20=
"formal_parameters")=20parent-bol=20java-ts-mode-indent-offset)=0A-=20=20=
=20=20=20((parent-is=20"formal_parameter")=20parent-bol=200)=0A+=20=20=20=
=20=20;;=20((parent-is=20"formal_parameters")=20parent-bol=20=
java-ts-mode-indent-offset)=0A+=20=20=20=20=20;;=20((parent-is=20=
"formal_parameter")=20parent-bol=200)=0A=20=20=20=20=20=20((parent-is=20=
"init_declarator")=20parent-bol=20java-ts-mode-indent-offset)=0A=20=20=20=
=20=20=20((parent-is=20"if_statement")=20parent-bol=20=
java-ts-mode-indent-offset)=0A=20=20=20=20=20=20((parent-is=20=
"for_statement")=20parent-bol=20java-ts-mode-indent-offset)=0A@@=20=
-164,7=20+175,8=20@@=20java-ts-mode--indent-rules=0A=20=20=20=20=20=20=
((parent-is=20"case_statement")=20parent-bol=20=
java-ts-mode-indent-offset)=0A=20=20=20=20=20=20((parent-is=20=
"labeled_statement")=20parent-bol=20java-ts-mode-indent-offset)=0A=20=20=20=
=20=20=20((parent-is=20"do_statement")=20parent-bol=20=
java-ts-mode-indent-offset)=0A-=20=20=20=20=20((parent-is=20"block")=20=
standalone-parent=20java-ts-mode-indent-offset)))=0A+=20=20=20=20=20;;=20=
((parent-is=20"block")=20standalone-parent=20java-ts-mode-indent-offset)=0A=
+=20=20=20=20=20c-ts-common-baseline-indent-rule))=0A=20=20=20=
"Tree-sitter=20indent=20rules.")=0A=20=0A=20(defvar=20=
java-ts-mode--keywords=0A@@=20-385,6=20+397,9=20@@=20java-ts-mode=0A=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(do=20.=20=
"do_statement")))=0A=20=20=20=20=20(setq-local=20=
c-ts-common-indent-offset=20'java-ts-mode-indent-offset)=0A=20=20=20=20=20=
(setq-local=20treesit-simple-indent-rules=20java-ts-mode--indent-rules)=0A=
+=20=20=20=20(setq-local=20treesit-simple-indent-standalone-predicate=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
#'java-ts-mode--standalone-predicate)=0A+=20=20=20=20(setq-local=20=
c-ts-common-list-indent-style=20'simple)=0A=20=0A=20=20=20=20=20;;=20=
Electric=0A=20=20=20=20=20(setq-local=20electric-indent-chars=0Adiff=20=
--git=20a/test/lisp/progmodes/java-ts-mode-resources/indent.erts=20=
b/test/lisp/progmodes/java-ts-mode-resources/indent.erts=0Aindex=20=
514d2e08977..7cf59340454=20100644=0A---=20=
a/test/lisp/progmodes/java-ts-mode-resources/indent.erts=0A+++=20=
b/test/lisp/progmodes/java-ts-mode-resources/indent.erts=0A@@=20-141,3=20=
+141,31=20@@=20public=20class=20Java=20{=0A=20=20=20=20=20}=0A=20}=0A=20=
=3D-=3D-=3D=0A+=0A+Name:=20Method=20chaining=0A+=0A+=3D-=3D=0A+public=20=
class=20FloodFill=20{=0A+public=20static=20void=20main(String[]=20args)=20=
{=0A+List<Foo>=20stream=20=3D=20students.stream(MAX_VALUE)=0A=
+.filter(item=20->=20{=0A+return=20item.getValue()=20>=20100=20&&=0A=
+item.isActive();=0A+})=0A+.map()=0A+.collect();=0A+}=0A+}=0A+=3D-=3D=0A=
+public=20class=20FloodFill=20{=0A+=20=20=20=20public=20static=20void=20=
main(String[]=20args)=20{=0A+=20=20=20=20=20=20=20=20List<Foo>=20stream=20=
=3D=20students.stream(MAX_VALUE)=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20.filter(item=20->=20{=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20return=20item.getValue()=20>=20100=20&&=0A+=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
item.isActive();=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20})=0A=
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20.map()=0A+=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20.collect();=0A+=20=20=20=20}=0A+}=0A=
+=3D-=3D-=3D=0A--=20=0A2.39.5=20(Apple=20Git-151)=0A=0A=
--Apple-Mail=_022B1C8E-3C16-4483-BA15-59767EA7529E
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=us-ascii
--Apple-Mail=_022B1C8E-3C16-4483-BA15-59767EA7529E--
bug-gnu-emacs@HIDDEN:bug#75154; Package emacs.
Full text available.
Received: (at 75154) by debbugs.gnu.org; 28 Jan 2025 14:06:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 28 09:06:46 2025
Received: from localhost ([127.0.0.1]:36072 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tcmEn-0004m0-A6
for submit <at> debbugs.gnu.org; Tue, 28 Jan 2025 09:06:46 -0500
Received: from mail-wm1-x332.google.com ([2a00:1450:4864:20::332]:55334)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <snake05865@HIDDEN>)
id 1tcmEk-0004lh-Al
for 75154 <at> debbugs.gnu.org; Tue, 28 Jan 2025 09:06:43 -0500
Received: by mail-wm1-x332.google.com with SMTP id
5b1f17b1804b1-436a03197b2so38293515e9.2
for <75154 <at> debbugs.gnu.org>; Tue, 28 Jan 2025 06:06:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1738073196; x=1738677996; darn=debbugs.gnu.org;
h=content-transfer-encoding:mime-version:message-id:date:references
:in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id
:reply-to; bh=dUI5tch0F9gRC6rBvMLK+HZlykfCs30yCiQSyRvf4Js=;
b=DpQTnbibfwwzjSmAfljorQtuoY+WVs32q2cQVk3gIBsXuyq4UP9uvCTUD/0nxYzY2H
S3YesUxAf1cURsc9jqzrt6cD489lkxEluUOp16Hefq/UpS4KpSDy+EV3tGoh54JtrSbG
udt0ib/G1/mv+PZqIxHcHXW32Wo2WUnqJDHjyliO0JWPv3yLgjdn8l96gr9pfVRSrKTA
WXLbOvi+v0GBpCCGTBwwOMPMQ5RU4SXGTTS4qArAfPsgDS3Srp5NS36cYuG93QmNvBng
PLRHApWNuEMXupgIzgxmF1dDMPppXrCiutLrlsuoqflB7krMQD1Npi4tvxFL55LVqPJt
dEQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1738073196; x=1738677996;
h=content-transfer-encoding:mime-version:message-id:date:references
:in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=dUI5tch0F9gRC6rBvMLK+HZlykfCs30yCiQSyRvf4Js=;
b=wjssEnVhlk9EJShrVWpUDkrf2cxFnW0aGtSRD8ISqUz1CfyV7iKcIDYbE1kVxLpU74
3IRzHPVjDqK3xWt35vNnN/L8RlCp9+8nQ8+hQauP9DEcfZwuTtfdqylWrUYXVzZCVxdE
sKaUolNihxJ2occ/rnoilqLewNwhBYkDBn24pkPjAjBU6g/g9Qml+9lWglVt1gLfvD8K
QR2Cb7mwe8JKz7grOkCjmci614qeACdSdUxI3hrY/OOF+9huu4MqxQWgczBS4B6dXQ8r
tY0eH1sgPuVtgzOsIW86o8QcdLN7yEXx87zNfyoZEzwh39cujgKXc6KGpypJjRonWU0j
w5fg==
X-Gm-Message-State: AOJu0Yza3hVaeBTmvGH8vdPFze5TKq8gIg6DhCdvCV5Ar4luLp6bSLFP
WHE9xhx+TM15/kGkcs3PAdshjaX3RtClu0Dq+SMg6+fYLMJUIIxs
X-Gm-Gg: ASbGncvv+6iNjYoxdas8jaqXzTJY3ao3ujAiHo2+ywnVJ08SVTL676TXXZAt/yVMYMF
nzrWgxcJQ03wylT8ZmjlzgPNY4tzHBDvJOYJrtXtUBPHQay7lQvnLhtANpMMqBxjHm/wMgmRoKo
rRSMyZO3Q0CiYNCLMJJd1enG6E1j9hEUFhxNSPYJRlxbdOo8SGclS5pmuW3esmNjHTexUxztFn2
CZJn4mHMsyknr0DZZlVrx4dtcH6h6WHkSCzS9wUfMzw06Jmjn7mw8BCvHfWRnuy90xrAayG/ca3
jO8fWA==
X-Google-Smtp-Source: AGHT+IFo5a27xBW+G/3VZO/9pjyVVnDYUIgKtwDtYpocGYLWXppD2tM52cGHhEzsZ57YtvnQapz7VQ==
X-Received: by 2002:adf:e283:0:b0:386:1cf9:b993 with SMTP id
ffacd0b85a97d-38bf57896ccmr26937449f8f.26.1738073195298;
Tue, 28 Jan 2025 06:06:35 -0800 (PST)
Received: from void ([77.51.149.106]) by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-38c2a1bb02dsm14223977f8f.70.2025.01.28.06.06.34
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Tue, 28 Jan 2025 06:06:34 -0800 (PST)
Received: from localhost (void [local])
by void (OpenSMTPD) with ESMTPA id 43363ab0;
Tue, 28 Jan 2025 14:06:33 +0000 (UTC)
From: Artem <snake05865@HIDDEN>
To: Theodor Thornhill <theo@HIDDEN>
Subject: Re: bug#75154: 31.0.50; java-ts-mode. Issues with Indentation
In-Reply-To: <87h66dv6r7.fsf@HIDDEN>
References: <87ttapdtre.fsf@void> <86pllcurry.fsf@HIDDEN>
<CADwFkmmEZ8bQE+eFRUUmyg8vTq802Yfon_RsNB87ugpGhdmOUQ@HIDDEN>
<87h66dv6r7.fsf@HIDDEN>
Date: Tue, 28 Jan 2025 17:06:33 +0300
Message-ID: <87cyg7dod2.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.2 (/)
X-Debbugs-Envelope-To: 75154
Cc: 75154 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
Stefan Kangas <stefankangas@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: -0.8 (/)
Okay, you may personally disagree. But why not create a separate
setting tailored to your preferences? You seem to agree that IntelliJ IDEA
is currently the canonical editor for Java. Set 8 spaces as the default and
add an option to adjust it.
Do I need to provide examples of major open-source projects that use 8 spac=
es?
For instance, Apache Tomcat:
https://github.com/apache/tomcat/blob/cd997770105ea960764c3d7844e13c0bbe8fd=
3c1/java/org/apache/juli/OneLineFormatter.java#L102
Or Red Hat Quarkus:
https://github.com/quarkusio/quarkus/blob/0e013fabfc14557e688b559f6edea43b8=
934406a/devtools/cli/src/main/java/io/quarkus/cli/CliPlugins.java#L37
I think this is a very important matter. Personally,
it drives me crazy when the spacing is off.
> 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=20
> }
> }
> ```
>
> Now we have a valid parse tree, indented correctly, and can continue
> chaining. I agree that this very much is a hack.
Yes, it does look unnatural. And you know, there=E2=80=99s a similar issue =
in bash-ts-mode.
I can=E2=80=99t show the exact code snippet right now, but the behavior is =
essentially the same.
You press RET, the cursor ends up in the wrong position, then press RET aga=
in,
and the code block jumps to where it=E2=80=99s supposed to be.
Where=E2=80=99s the error? Is it a problem with the mode=E2=80=99s implemen=
tation
or a bug in Tree-sitter itself? Or did everyone just borrow logic from
each other, and now this indentation behavior has spread to other modes?
>
>> 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();
>> }
>> }
I=E2=80=99m not sure. Maybe I can create a new bug report? But honestly,
I don=E2=80=99t understand the point. A new report just to track the resolu=
tion
of some minor issue that annoys you and that you consider more important th=
an others?
>>=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.
Yes, I=E2=80=99ve already figured that out, thank you. But what does it giv=
e me? Am I supposed
to just live with it? By the way, I tried disabling electric-indent-mode, b=
ut then indentation
stopped working entirely. I briefly went through the documentation to under=
stand what=E2=80=99s going on,
and from what I gathered, this mode uses various backends, including Tree-s=
itter now.
I could be wrong, but it seems like electric-indent-mode needs a review and=
a rethinking
of how it should work, considering Tree-sitter is being actively used.
And the extra =E2=80=9Cmagic=E2=80=9D performed by electric-indent-mode mig=
ht have been relevant a long
time ago, or maybe it still is in some cases. But for Java/C/C++, I don=E2=
=80=99t see why
it=E2=80=99s necessary. It=E2=80=99s just annoying and gets in the way.
>> 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 i=
ncorrectly 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=20
> }
> }
> ```
>
> Indentation at column 8 is expected here, IMO. I'm not sure we should
> try to work around clearly "incorrectly" indented code.
In my understanding, and in IntelliJ IDEA=E2=80=99s, it should work so that
it doesn=E2=80=99t matter what syntactic construct, method, or anything els=
e is far
behind=E2=80=94several levels above, to be exact. Tree-sitter should only c=
are
about what=E2=80=99s one step behind you. It shouldn=E2=80=99t matter to yo=
u that the Inner
class is misplaced. Your method foo() should focus on where it belongs, even
if the Inner class has incorrect indentation. This isn=E2=80=99t a hack. It=
feels
natural=E2=80=94just follow what=E2=80=99s next to you.=20=20
Right now, it=E2=80=99s just a tightly coupled construct where breaking one
thing breaks another=E2=80=94or everything altogether.=20=20
>
>>=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
>
Yes, this is invalid code. Again, this touches on how indentation works.
The machine and the code should think like me:
"You see I=E2=80=99ve placed triple quotes? You see there=E2=80=99s a metho=
d earlier?
Guess what I=E2=80=99m about to write? Of course, it=E2=80=99s going to be =
a TEXT BLOCK! Bingo!"
There=E2=80=99s nothing else I could possibly write there.
> ```
> 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
> }
> ```
Even if I write this code correctly, I still don't have the proper indentat=
ion.
Did you configure anything additional on your end? Out of the box, this doe=
sn't work for me
public class TextBlocks {
void foo() {
System.out.println(ctx.fetch(""" <-- 1. press RET=20
| <-- and you will be here (Actual)=20
| <-- Expected
"""));
}
}
java-mode, unlike java-ts-mode, is a bit smarter in this regard - the inden=
tation is at least
somewhat recognized, but it still ends up in the wrong place. Manual adjust=
ment of rules is required.
> I usually indent stuff like this marking the region then using C-x i
> then <left> or <right>
What is C-x i? For me it's insert-file.
>
>> - New SQL expressions should be sticky
> What do you mean here? Align the newlines to the previous line?
I've already forgotten what I meant. But yes, sticky means aligning the new=
line according
to the previous line. I think I saw this somewhere or maybe
I'm confusing it with Stream API method chains.
>> 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
>
Looks like I said too much here. I apologize. Yes, this works correctly.
For example, such code will make proper indentation
String sql =3D "SELECT u.id, u.name, u.email, COUNT(o.id) AS order_coun=
t " +
"FROM users u " +
"LEFT JOIN orders o ON u.id =3D o.user_id " +
>> 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?
There's nothing broken in the code above. But in java-ts-mode it looks like=
this:
public record StudentRecord(
String a,
String b, <--Actual (BAD)
String b <--Expected (Good)=20=20=20=20=20
)
>> 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?
Current behavior in java-ts-mode:
public String filterData(@RequestParam(required =3D false) String name,
@RequestParam(required =3D false) String name, <--Actual
@RequestParam(required =3D false) <--Expected
)
You understand, I can't even press TAB to move this over?
>> 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?
These might be my personal wishes. But didn't some of this work out of the =
box in java-mode?
Am I right about this? Why did this disappear in java-ts-mode?
Actually, I wouldn't worry about this if I could simply press M-x customize=
and select
the needed colors. But... For some reason it's not that simple. In general,
custom color highlighting setup isn't very oriented towards people without =
Elisp knowledge.
Doesn't Emacs philosophy assume that many settings should be done this way
and all of this is then saved in custom.el?
>> - 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 =
somewhat 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 unpolish=
ed.=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.
You know what I thought about? I thought that since treesitter
builds a syntax tree of the file, it should be able to know what
in this tree has no usage and isn't connected to anything.
>> 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.
What priority for each problem? For me, everything is priority.
Maybe for someone who understands Elisp well, some things might be less urg=
ent.
Very very very many people don't write anything in the bug tracker.
Because many things can really look like the user just needs to open
the Emacs Lisp references manual and do it themselves, rather than asking s=
omeone to do it for them.
Slightly off-topic....
Actually, I realized long ago that many things in Emacs are made so that us=
ers are given
some sandbox and provided opportunities to play in it themselves and custom=
ize it to their taste.
But there aren't many things that are really polished and designed to just =
open and use.
I haven't tried many programming modes. But recently I discovered Racket-mo=
de.
God, how neat, polished, well-thought-out this mode looks and requires almo=
st no additional setup
from the user, and tons of documentation is written.
For Java, which is in the top 3 languages worldwide, there is NOTHING in Em=
acs.
More precisely, there was something and it's probably gathering dust somewh=
ere deep in Emacs' depths,
something like JDEE or CEDET which 1-2 people use. And nobody talks about t=
his now and nowhere
is it written about. You need to do some research work to understand what w=
as relevant before
and what wasn't.
Do you understand that there isn't even a "run main" button?
This is funny and sad.
> 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.
That's cool. I want to be like you and be the only Java developer who works=
in Emacs,
but reality is quite different for now. There's so much! So much! That need=
s to be finished.
Well okay, I'm lying, not that much.
I think attaching transient.el + hydra.el + a couple dozen functions and th=
is should
become almost indistinguishable from IDE and maybe even superior in some pl=
aces.
But this still needs to be done...
>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.
>
>
> 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.
As soon as there's some interested person who wants to do some refactoring
of everything that was previously done for JAVA in Emacs
and rewrites/writes/adapts it to new realities.
I'll be able to officially declare that Emacs will be the best editor/IDE f=
or Java.
But for now, that person hasn't been born yet. Or maybe it all exists alrea=
dy,
but somewhere in personal repositories on GitHub or somewhere else,
but won't make it into the core of java-ts-mode.
I know you're not the only one who writes Java in Emacs and remains product=
ive.
But... I expressed my thoughts about the situation earlier.
And you understand these are thoughts of an ordinary person, not an Emacs h=
acker.
If you can do it, it doesn't mean that thousands of others can do exactly t=
he same.
bug-gnu-emacs@HIDDEN:bug#75154; Package emacs.
Full text available.
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.