bug#5410: Parenthesis Matching Bug!!

bug#5410: Parenthesis Matching Bug!!

[Matrix]

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!!!

bug#5410: Parenthesis Matching Bug!!

[Andrew Hyatt]

Matrix <min.matrix@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?

bug#5410: Parenthesis Matching Bug!!

[Michael Heerdegen]

Andrew Hyatt <ahyatt@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.

bug#5410: Parenthesis Matching Bug!!

[Andrew Hyatt]

[-- Attachment #1: Type: text/plain, Size: 1567 bytes --]

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

> Andrew Hyatt <ahyatt@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.
>

[-- Attachment #2: Type: text/html, Size: 2465 bytes --]

bug#5410: Parenthesis Matching Bug!!

[Michael Heerdegen]

Andrew Hyatt <ahyatt@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.

bug#5410: Parenthesis Matching Bug!!

[Andrew Hyatt]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Andrew Hyatt <ahyatt@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.

bug#5410: Parenthesis Matching Bug!!

[Michael Heerdegen]

Andrew Hyatt <ahyatt@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.

bug#5410: bug#5411: show-paren-mode and parens spread over multi-line comments

[Lars Ingebrigtsen]

Matrix <min.matrix@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