GNU bug report logs -
#69571
29.2; csharp-mode indentation: Misaligned closing brace in blocks starting below "new"
Previous Next
Reported by: Carlos <carlos <at> cvkm.cz>
Date: Tue, 5 Mar 2024 21:49:02 UTC
Severity: normal
Found in version 29.2
Fixed in version 29.2
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 69571 in the body.
You can then email your comments to 69571 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#69571
; Package
emacs
.
(Tue, 05 Mar 2024 21:49:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Carlos <carlos <at> cvkm.cz>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 05 Mar 2024 21:49:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Any block starting on the line immediately below a line having the
string "new" will have its closing brace aligned with the opening one.
See the following code:
public class Foo {
void Bar () {
var x = new X(); // [1]
for (;;) {
x();
} // [2]
}
}
Line [1] says "new". The closing brace in line [2] is aligned to the
opening brace.
If you comment out the "new" (or the whole line) the problem persists.
If you remove the "new" the problem goes away and [2] is correctly
aligned.
If you insert a line between line [1] and the one having the opening
brace the problem goes away.
In GNU Emacs 29.2 (build 2, x86_64-w64-mingw32) of 2024-02-29 built on
fv-az586-734
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Pro (v10.0.2009.19045.4046)
Configured using:
'configure --prefix=/mingw64 --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --with-modules --without-dbus
--without-compress-install --with-tree-sitter
--with-native-compilation=aot 'CFLAGS=-march=nocona -msahf
-mtune=generic -O2 -pipe -fstack-protector-strong
-fno-optimize-sibling-calls' CPPFLAGS=-D__USE_MINGW_ANSI_STDIO=1
'LDFLAGS=-pipe -lpthread''
Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LIBXML2 MODULES NATIVE_COMP NOTIFY
W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB
Important settings:
value of $LANG: ENU
locale-coding-system: cp1252
Major mode: C#//l
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils mule-util info time-date comp comp-cstr
warnings icons subr-x rx cl-macs gv cl-extra help-mode bytecomp
byte-compile csharp-mode c-ts-common treesit cl-seq cc-langs cc-mode
cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars
cc-defs cl-loaddefs cl-lib compile text-property-search comint ansi-osc
ansi-color ring rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32
ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads
w32notify w32 multi-tty make-network-process native-compile emacs)
Memory information:
((conses 16 151774 16013)
(symbols 48 10722 0)
(strings 32 38006 1798)
(string-bytes 1 1194803)
(vectors 16 23175)
(vector-slots 8 439354 17596)
(floats 8 37 72)
(intervals 56 1626 0)
(buffers 984 15))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#69571
; Package
emacs
.
(Sat, 09 Mar 2024 08:40:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 69571 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 5 Mar 2024 22:09:51 +0100
> From: Carlos <carlos <at> cvkm.cz>
>
> Any block starting on the line immediately below a line having the
> string "new" will have its closing brace aligned with the opening one.
>
> See the following code:
>
> public class Foo {
> void Bar () {
> var x = new X(); // [1]
> for (;;) {
> x();
> } // [2]
> }
> }
>
> Line [1] says "new". The closing brace in line [2] is aligned to the
> opening brace.
>
> If you comment out the "new" (or the whole line) the problem persists.
>
> If you remove the "new" the problem goes away and [2] is correctly
> aligned.
>
> If you insert a line between line [1] and the one having the opening
> brace the problem goes away.
Theo and Yuan, could you please look into this?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#69571
; Package
emacs
.
(Sat, 09 Mar 2024 09:55:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 69571 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#69571
; Package
emacs
.
(Sun, 10 Mar 2024 19:23:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 69571 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Tue, 5 Mar 2024 22:09:51 +0100
>> From: Carlos <carlos <at> cvkm.cz>
>>
>> Any block starting on the line immediately below a line having the
>> string "new" will have its closing brace aligned with the opening one.
>>
>> See the following code:
>>
>> public class Foo {
>> void Bar () {
>> var x = new X(); // [1]
>> for (;;) {
>> x();
>> } // [2]
>> }
>> }
>>
>> Line [1] says "new". The closing brace in line [2] is aligned to the
>> opening brace.
>>
>> If you comment out the "new" (or the whole line) the problem persists.
>>
>> If you remove the "new" the problem goes away and [2] is correctly
>> aligned.
>>
>> If you insert a line between line [1] and the one having the opening
>> brace the problem goes away.
>
> Theo and Yuan, could you please look into this?
I have a working patch for this, but I'd like to expand it to cover an
edge case for which I'm unable to find a good solution. Can you suggest
a way around this edge case?
Consider the provided code:
```
public class Foo {
void Bar () {
var x = new X(); // [1]
for (;;) {
x();
} // [2]
}
}
```
Like this, the below patch doesn't work. If you remove the first
comment, the patch works.
```
public class Foo {
void Bar () {
var x = new X();
for (;;) {
x();
} // [2]
}
}
```
The reason is simple, of course. What I'm struggling with here is how to
best handle the case where there is a comment ending the line, possibly
containing a ';' itself. I've tried some variations with save-excursion
along with syntax-ppss to detect whether or not we're in a comment, but
it gets verbose and ugly. Is there some simple way to do this check in
Emacs, or should I just resort to making some best effort judgement call
here?
Thanks,
Theo
diff --git a/lisp/progmodes/csharp-mode.el b/lisp/progmodes/csharp-mode.el
index 7bf57bcbe21..00278e18e51 100644
--- a/lisp/progmodes/csharp-mode.el
+++ b/lisp/progmodes/csharp-mode.el
@@ -495,9 +495,10 @@ csharp-guess-basic-syntax
(unless (eq (char-after) ?{)
(ignore-errors (backward-up-list 1 t t)))
(save-excursion
- ;; 'new' should be part of the line
+ ;; 'new' should be part of the line, but should not trigger if
+ ;; statement has already ended, like for 'var x = new X();'.
(goto-char (c-point 'iopl))
- (looking-at ".*new.*")))
+ (looking-at ".*new.*[^;]$")))
;; Line should not already be terminated
(save-excursion
(goto-char (c-point 'eopl))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#69571
; Package
emacs
.
(Sat, 16 Mar 2024 11:21:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 69571 <at> debbugs.gnu.org (full text, mbox):
Ping! Yuan, could help Theo figure out what's best here?
> From: Theodor Thornhill <theo <at> thornhill.no>
> Cc: 69571 <at> debbugs.gnu.org
> Date: Sun, 10 Mar 2024 20:21:32 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Date: Tue, 5 Mar 2024 22:09:51 +0100
> >> From: Carlos <carlos <at> cvkm.cz>
> >>
> >> Any block starting on the line immediately below a line having the
> >> string "new" will have its closing brace aligned with the opening one.
> >>
> >> See the following code:
> >>
> >> public class Foo {
> >> void Bar () {
> >> var x = new X(); // [1]
> >> for (;;) {
> >> x();
> >> } // [2]
> >> }
> >> }
> >>
> >> Line [1] says "new". The closing brace in line [2] is aligned to the
> >> opening brace.
> >>
> >> If you comment out the "new" (or the whole line) the problem persists.
> >>
> >> If you remove the "new" the problem goes away and [2] is correctly
> >> aligned.
> >>
> >> If you insert a line between line [1] and the one having the opening
> >> brace the problem goes away.
> >
> > Theo and Yuan, could you please look into this?
>
> I have a working patch for this, but I'd like to expand it to cover an
> edge case for which I'm unable to find a good solution. Can you suggest
> a way around this edge case?
>
> Consider the provided code:
> ```
> public class Foo {
> void Bar () {
> var x = new X(); // [1]
> for (;;) {
> x();
> } // [2]
> }
> }
> ```
>
> Like this, the below patch doesn't work. If you remove the first
> comment, the patch works.
>
> ```
> public class Foo {
> void Bar () {
> var x = new X();
> for (;;) {
> x();
> } // [2]
> }
> }
> ```
>
> The reason is simple, of course. What I'm struggling with here is how to
> best handle the case where there is a comment ending the line, possibly
> containing a ';' itself. I've tried some variations with save-excursion
> along with syntax-ppss to detect whether or not we're in a comment, but
> it gets verbose and ugly. Is there some simple way to do this check in
> Emacs, or should I just resort to making some best effort judgement call
> here?
>
> Thanks,
> Theo
>
> diff --git a/lisp/progmodes/csharp-mode.el b/lisp/progmodes/csharp-mode.el
> index 7bf57bcbe21..00278e18e51 100644
> --- a/lisp/progmodes/csharp-mode.el
> +++ b/lisp/progmodes/csharp-mode.el
> @@ -495,9 +495,10 @@ csharp-guess-basic-syntax
> (unless (eq (char-after) ?{)
> (ignore-errors (backward-up-list 1 t t)))
> (save-excursion
> - ;; 'new' should be part of the line
> + ;; 'new' should be part of the line, but should not trigger if
> + ;; statement has already ended, like for 'var x = new X();'.
> (goto-char (c-point 'iopl))
> - (looking-at ".*new.*")))
> + (looking-at ".*new.*[^;]$")))
> ;; Line should not already be terminated
> (save-excursion
> (goto-char (c-point 'eopl))
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#69571
; Package
emacs
.
(Sat, 16 Mar 2024 17:03:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 69571 <at> debbugs.gnu.org (full text, mbox):
On 16/03/2024 13:19, Eli Zaretskii wrote:
> Ping! Yuan, could help Theo figure out what's best here?
csharp-mode is based on CC Mode, not tree-sitter.
So maybe Alan will want to comment.
(csharp-ts-mode doesn't have this problem.)
>> From: Theodor Thornhill <theo <at> thornhill.no>
>> Cc: 69571 <at> debbugs.gnu.org
>> Date: Sun, 10 Mar 2024 20:21:32 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> Date: Tue, 5 Mar 2024 22:09:51 +0100
>>>> From: Carlos <carlos <at> cvkm.cz>
>>>>
>>>> Any block starting on the line immediately below a line having the
>>>> string "new" will have its closing brace aligned with the opening one.
>>>>
>>>> See the following code:
>>>>
>>>> public class Foo {
>>>> void Bar () {
>>>> var x = new X(); // [1]
>>>> for (;;) {
>>>> x();
>>>> } // [2]
>>>> }
>>>> }
>>>>
>>>> Line [1] says "new". The closing brace in line [2] is aligned to the
>>>> opening brace.
>>>>
>>>> If you comment out the "new" (or the whole line) the problem persists.
>>>>
>>>> If you remove the "new" the problem goes away and [2] is correctly
>>>> aligned.
>>>>
>>>> If you insert a line between line [1] and the one having the opening
>>>> brace the problem goes away.
>>>
>>> Theo and Yuan, could you please look into this?
>>
>> I have a working patch for this, but I'd like to expand it to cover an
>> edge case for which I'm unable to find a good solution. Can you suggest
>> a way around this edge case?
>>
>> Consider the provided code:
>> ```
>> public class Foo {
>> void Bar () {
>> var x = new X(); // [1]
>> for (;;) {
>> x();
>> } // [2]
>> }
>> }
>> ```
>>
>> Like this, the below patch doesn't work. If you remove the first
>> comment, the patch works.
>>
>> ```
>> public class Foo {
>> void Bar () {
>> var x = new X();
>> for (;;) {
>> x();
>> } // [2]
>> }
>> }
>> ```
>>
>> The reason is simple, of course. What I'm struggling with here is how to
>> best handle the case where there is a comment ending the line, possibly
>> containing a ';' itself. I've tried some variations with save-excursion
>> along with syntax-ppss to detect whether or not we're in a comment, but
>> it gets verbose and ugly. Is there some simple way to do this check in
>> Emacs, or should I just resort to making some best effort judgement call
>> here?
>>
>> Thanks,
>> Theo
>>
>> diff --git a/lisp/progmodes/csharp-mode.el b/lisp/progmodes/csharp-mode.el
>> index 7bf57bcbe21..00278e18e51 100644
>> --- a/lisp/progmodes/csharp-mode.el
>> +++ b/lisp/progmodes/csharp-mode.el
>> @@ -495,9 +495,10 @@ csharp-guess-basic-syntax
>> (unless (eq (char-after) ?{)
>> (ignore-errors (backward-up-list 1 t t)))
>> (save-excursion
>> - ;; 'new' should be part of the line
>> + ;; 'new' should be part of the line, but should not trigger if
>> + ;; statement has already ended, like for 'var x = new X();'.
>> (goto-char (c-point 'iopl))
>> - (looking-at ".*new.*")))
>> + (looking-at ".*new.*[^;]$")))
>> ;; Line should not already be terminated
>> (save-excursion
>> (goto-char (c-point 'eopl))
>>
>
>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#69571
; Package
emacs
.
(Sat, 16 Mar 2024 17:27:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 69571 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#69571
; Package
emacs
.
(Sat, 16 Mar 2024 19:47:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 69571 <at> debbugs.gnu.org (full text, mbox):
>>> Date: Tue, 5 Mar 2024 22:09:51 +0100
>>> From: Carlos <carlos <at> cvkm.cz>
>>>
>>> If you insert a line between line [1] and the one having the opening
>>> brace the problem goes away.
>>
>> Theo and Yuan, could you please look into this?
Fixed in c890622e1a9ae6f2ab5d083ca8b668c9228c52fa on emacs-29.
Theo
bug Marked as fixed in versions 29.2.
Request was from
Theodor Thornhill <theo <at> thornhill.no>
to
control <at> debbugs.gnu.org
.
(Sat, 16 Mar 2024 19:49:01 GMT)
Full text and
rfc822 format available.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Sat, 16 Mar 2024 20:13:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Carlos <carlos <at> cvkm.cz>
:
bug acknowledged by developer.
(Sat, 16 Mar 2024 20:13:02 GMT)
Full text and
rfc822 format available.
Message #33 received at 69571-done <at> debbugs.gnu.org (full text, mbox):
> From: Theodor Thornhill <theo <at> thornhill.no>
> Cc: 69571 <at> debbugs.gnu.org
> Date: Sat, 16 Mar 2024 20:45:36 +0100
>
>
> >>> Date: Tue, 5 Mar 2024 22:09:51 +0100
> >>> From: Carlos <carlos <at> cvkm.cz>
>
> >>>
> >>> If you insert a line between line [1] and the one having the opening
> >>> brace the problem goes away.
> >>
> >> Theo and Yuan, could you please look into this?
>
>
>
> Fixed in c890622e1a9ae6f2ab5d083ca8b668c9228c52fa on emacs-29.
Thanks!
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#69571
; Package
emacs
.
(Sat, 30 Mar 2024 12:16:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 69571 <at> debbugs.gnu.org (full text, mbox):
> - (looking-at ".*new.*")))
> + (looking-at "^[^//]*new[^//]*;$")))
That regexp doesn't look right: [^//] doesn't mean "no occurrence of double-slash" but is just the same as [^/].
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#69571
; Package
emacs
.
(Sat, 30 Mar 2024 12:31:01 GMT)
Full text and
rfc822 format available.
Message #39 received at 69571 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#69571
; Package
emacs
.
(Sun, 31 Mar 2024 08:59:01 GMT)
Full text and
rfc822 format available.
Message #42 received at 69571 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:
>> - (looking-at ".*new.*")))
>> + (looking-at "^[^//]*new[^//]*;$")))
>
>
> That regexp doesn't look right: [^//] doesn't mean "no occurrence of double-slash" but is just the same as [^/].
Pushed a new commit doing more shenanigans here, along with more tests.
Thanks
theo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#69571
; Package
emacs
.
(Sun, 31 Mar 2024 09:43:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 69571 <at> debbugs.gnu.org (full text, mbox):
31 mars 2024 kl. 10.57 skrev Theodor Thornhill <theo <at> thornhill.no>:
> Pushed a new commit doing more shenanigans here, along with more tests.
Thanks, no more regexp complaints at least!
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 28 Apr 2024 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 6 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.