GNU bug report logs - #5410
show-paren-mode and parens spread over multi-line comments

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 5410 in the body.
You can then email your comments to 5410 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Matrix <min.matrix <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Parenthesis Matching Bug!!
Date: Mon, 18 Jan 2010 20:20:37 +0800

Hello , developer! I am a student of china . I like emacs very much .
I use it to read txt-format book(because the color-theme of my emacs is
very good for eye!^^) . I also use emacs to coding!good~!!
   But now I find a bug in emacs :( . May be it`s not a bug , I want to
believe this.Now The-Bug as follow:

   //      Print a message and dump core (equivalent to ASSERT(FALSE)
without
//      making the compiler whine).

   The Parenthesis-Matching-highlight is work with the second '(' .
yeah  , When my cursor at the second '(' the first ')' highlight . But
when my cursor at first '(' , the second ')' doesn`t highlight and show 
unmatch Parenthesis....I think this is wrong , It match as:  (  ( )  ).

   ^^ , I like emacs , I want it  to be  more good tool for me and other
programer!!
   Thanks developers!!!

Message #16 received at 5410 <at> debbugs.gnu.org (full text, mbox):

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: Matrix <min.matrix <at> gmail.com>
Cc: 5410 <at> debbugs.gnu.org
Subject: Re: bug#5410: Parenthesis Matching Bug!!
Date: Wed, 03 Aug 2016 22:18:50 -0400

Matrix <min.matrix <at> gmail.com> writes:

> Hello , developer! I am a student of china . I like emacs very much .
> I use it to read txt-format book(because the color-theme of my emacs is
> very good for eye!^^) . I also use emacs to coding!good~!!
>    But now I find a bug in emacs :( . May be it`s not a bug , I want to
> believe this.Now The-Bug as follow:
>
>    //      Print a message and dump core (equivalent to ASSERT(FALSE)
> without
> //      making the compiler whine).
>
>    The Parenthesis-Matching-highlight is work with the second '(' .
> yeah  , When my cursor at the second '(' the first ')' highlight . But
> when my cursor at first '(' , the second ')' doesn`t highlight and show 
> unmatch Parenthesis....I think this is wrong , It match as:  (  ( )  ).
>
>    ^^ , I like emacs , I want it  to be  more good tool for me and other
> programer!!
>    Thanks developers!!!

Hi, sorry for the late reply.

Your example reproduces for me in Emacs 25. My guess is that emacs
doesn't really assume that comment lines should be treated as a
contiguous text block. Which is sometimes right, sometimes not, in my
experience.  For example, you could have comments that are something
like:

// This function does three things:
// 1) Reverse the string
// 2) Uuencode the string
// 3) Rot-13 the string

Which certainly wouldn't make a lot of sense treated contiguously.

Does anyone have any opinions whether this is a bug or a wishlish item?

Message #19 received at 5410 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Andrew Hyatt <ahyatt <at> gmail.com>
Cc: 5410 <at> debbugs.gnu.org, Matrix <min.matrix <at> gmail.com>
Subject: Re: bug#5410: Parenthesis Matching Bug!!
Date: Thu, 04 Aug 2016 04:55:16 +0200

Andrew Hyatt <ahyatt <at> gmail.com> writes:

> Your example reproduces for me in Emacs 25. My guess is that emacs
> doesn't really assume that comment lines should be treated as a
> contiguous text block. Which is sometimes right, sometimes not, in my
> experience.

We are talking about `show-paren-mode', right?  AFAICT this just calls
`scan-sexps' and looks if that errors or not, without doing syntactical
analysis itself.

`parse-sexp-ignore-comments' influences `scan-sexps's behavior in this
regard, and setting it to nil does change the behavior in this case for
me.  I guess we could use this for a solution.

> For example, you could have comments that are something
> like:
>
> // This function does three things:
> // 1) Reverse the string
> // 2) Uuencode the string
> // 3) Rot-13 the string
>
> Which certainly wouldn't make a lot of sense treated contiguously.

Well, we would not loose anything in this case: parens are already shown
as mismatches now.


Michael.

Message #22 received at 5410 <at> debbugs.gnu.org (full text, mbox):

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 5410 <at> debbugs.gnu.org, Matrix <min.matrix <at> gmail.com>
Subject: Re: bug#5410: Parenthesis Matching Bug!!
Date: Thu, 04 Aug 2016 20:17:08 +0000

[Message part 1 (text/plain, inline)]

On Wed, Aug 3, 2016 at 10:55 PM Michael Heerdegen <michael_heerdegen <at> web.de>
wrote:

> Andrew Hyatt <ahyatt <at> gmail.com> writes:
>
> > Your example reproduces for me in Emacs 25. My guess is that emacs
> > doesn't really assume that comment lines should be treated as a
> > contiguous text block. Which is sometimes right, sometimes not, in my
> > experience.
>
> We are talking about `show-paren-mode', right?  AFAICT this just calls
> `scan-sexps' and looks if that errors or not, without doing syntactical
> analysis itself.
>


> `parse-sexp-ignore-comments' influences `scan-sexps's behavior in this
> regard, and setting it to nil does change the behavior in this case for
> me.  I guess we could use this for a solution.2
>

Yes, this works to resolve the issue for me too.  Are you saying it should
default to nil always, or for cc-mode?  It seems like setting this to nil
might cause other issues we wouldn't want; ignoring comments usually seems
like the right thing to do.

It'd be nice, I guess, if you could just turn it to nil when in a comment.


>
> > For example, you could have comments that are something
> > like:
> >
> > // This function does three things:
> > // 1) Reverse the string
> > // 2) Uuencode the string
> > // 3) Rot-13 the string
> >
> > Which certainly wouldn't make a lot of sense treated contiguously.
>
> Well, we would not loose anything in this case: parens are already shown
> as mismatches now.
>
>
True, I guess my point is that it'd be strange to consider this as 3
unmatched parens rather than 1 per line.


>
> Michael.
>

[Message part 2 (text/html, inline)]

Message #25 received at 5410 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Andrew Hyatt <ahyatt <at> gmail.com>
Cc: 5410 <at> debbugs.gnu.org, Matrix <min.matrix <at> gmail.com>
Subject: Re: bug#5410: Parenthesis Matching Bug!!
Date: Thu, 04 Aug 2016 23:47:24 +0200

Andrew Hyatt <ahyatt <at> gmail.com> writes:

> It'd be nice, I guess, if you could just turn it to nil when in a
> comment.

Yes, I think we could bind `parse-sexp-ignore-comments' to nil around
the calls to `scan-sexps' in `show-paren--default' when point is inside
a comment.  But I must admit that I don't understand the terse doc of
`parse-sexp-ignore-comments':

|  Non-nil means `forward-sexp', etc., should treat comments as
|  whitespace.

But what does nil mean, exactly?  It seems that comments are then
treated as if they were indistinguishable from code.  When I set
`parse-sexp-ignore-comments' to nil in emacs-lisp-mode, and have such a
file:

;; (
)

then show-paren-mode indicates the parens as matching, though one is
inside in a comment, and the other is not.  `scan-sexps' behaves
accordingly.  That would mean we would need to assure that the matching
paren position that `scan-sexps' has found is still inside the current
comment.


Michael.

Message #28 received at 5410 <at> debbugs.gnu.org (full text, mbox):

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Matrix <min.matrix <at> gmail.com>, 5410 <at> debbugs.gnu.org
Subject: Re: bug#5410: Parenthesis Matching Bug!!
Date: Wed, 10 Aug 2016 23:57:36 -0400

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Andrew Hyatt <ahyatt <at> gmail.com> writes:
>
>> It'd be nice, I guess, if you could just turn it to nil when in a
>> comment.
>
> Yes, I think we could bind `parse-sexp-ignore-comments' to nil around
> the calls to `scan-sexps' in `show-paren--default' when point is inside
> a comment.  But I must admit that I don't understand the terse doc of
> `parse-sexp-ignore-comments':
>
> |  Non-nil means `forward-sexp', etc., should treat comments as
> |  whitespace.
>
> But what does nil mean, exactly?  It seems that comments are then
> treated as if they were indistinguishable from code.  When I set
> `parse-sexp-ignore-comments' to nil in emacs-lisp-mode, and have such a
> file:
>
> ;; (
> )
>
> then show-paren-mode indicates the parens as matching, though one is
> inside in a comment, and the other is not.  `scan-sexps' behaves
> accordingly.  That would mean we would need to assure that the matching
> paren position that `scan-sexps' has found is still inside the current
> comment.

Interesting point.  The more I hear, the more this sounds like a
wishlist item - we just don't seem to have a way to treat paren matching
in comments separately yet with multiline capabilities.  I'm going to
mark it as wishlist for now.

>
>
> Michael.

Message #33 received at 5410 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Andrew Hyatt <ahyatt <at> gmail.com>
Cc: Matrix <min.matrix <at> gmail.com>, 5410 <at> debbugs.gnu.org
Subject: Re: bug#5410: Parenthesis Matching Bug!!
Date: Tue, 23 Aug 2016 17:02:28 +0200

Andrew Hyatt <ahyatt <at> gmail.com> writes:

> Interesting point.  The more I hear, the more this sounds like a
> wishlist item - we just don't seem to have a way to treat paren
> matching in comments separately yet with multiline capabilities.  I'm
> going to mark it as wishlist for now.

I agree - thanks.

FWIW I had filed

  bug#24172: 25.1; Doc of parse-sexp-ignore-comments: what does a value
  of nil mean?

When once it has been fixed, we'll know better how to fix this issue.


Michael.

Message #36 received at 5410 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Matrix <min.matrix <at> gmail.com>
Cc: 5410 <at> debbugs.gnu.org
Subject: Re: bug#5411: show-paren-mode and parens spread over multi-line
 comments
Date: Mon, 02 May 2022 11:02:32 +0200

Matrix <min.matrix <at> gmail.com> writes:

>    But now I find a bug in emacs :( . May be it`s not a bug , I want to
> believe this.Now The-Bug as follow:
>
>    //      Print a message and dump core (equivalent to ASSERT(FALSE)
> without
> //      making the compiler whine).
>
>    The Parenthesis-Matching-highlight is work with the second '(' .
> yeah  , When my cursor at the second '(' the first ')' highlight . But
> when my cursor at first '(' , the second ')' doesn`t highlight and show 
> unmatch Parenthesis....I think this is wrong , It match as:  (  ( )  ).

I've now fixed this in Emacs 29 (just 12 years after it was reported
😀).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.