bug#5122: Mismatched parentheses when dealing with huge buffer content

bug#5122: Mismatched parentheses when dealing with huge buffer content

[Deniz Dogan]

In GNU Emacs 23.1.1 (i386-mingw-nt6.0.6002)
 of 2009-07-30 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 6.0.6002
configured using `configure --with-gcc (4.4)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  shell-dirtrack-mode: t
  rcirc-track-minor-mode: t
  diff-auto-refine-mode: t
  yas/global-mode: t
  yas/minor-mode: t
  global-auto-complete-mode: t
  auto-complete-mode: t
  cua-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v
C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v
C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v
C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v
M-k C-n <C-return> M-f C-g C-g <C-return> C-f C-f C-f
C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f
C-f C-f C-f C-f C-f C-f C-f C-f C-v C-v C-v C-v C-v
C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v
C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v
C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v
C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v
C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v
C-v C-v C-v C-v C-v C-v C-v M-v M-v M-v M-v M-v M-v
M-v M-v M-v M-v C-v C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n M-k C-g M-< C-n C-p M-n
C-p C-e <backspace> ) C-t C-s M-< M-n M-v <down-mouse-1>
<mouse-movement> <down-mouse-4> <drag-mouse-1> C-t
o C-t C-g C-h v <up> <return> C-n C-n C-n C-t o C-n
C-n C-n C-n C-n C-n C-n C-SPC M-n M-w C-t o C-t u s
c r a <return> C-y M-< C-n C-n M-> C-p C-e <backspace>
) M-x r e p o r t - e m a c s <tab> <return>

When taking the value of ucs-completions given by C-h v
ucs-completions and inserting it in the scratch buffer, Emacs is
unable to determine that a correct parentheses match is made. (Pardon
my English.) I simply remove the last of the two trailing parentheses
of the expression and insert a new trailing parenthesis (making the
content identical to what it was initially), and I get "Mismatched
parentheses".

-- 
Deniz Dogan

bug#5122: Mismatched parentheses when dealing with huge buffercontent

[Drew Adams]

See option `blink-matching-paren-distance' and node Matching in the Emacs
manual.

Does increasing that variable's value resolve the problem? 

bug#5122: Mismatched parentheses when dealing with huge buffercontent

[Deniz Dogan]

2009/12/4 Drew Adams <drew.adams@oracle.com>:
> See option `blink-matching-paren-distance' and node Matching in the Emacs
> manual.
>
> Does increasing that variable's value resolve the problem?
>
>

Yes, it does solve the problem.

-- 
Deniz Dogan

bug#5122: Mismatched parentheses when dealing with huge buffercontent

[Drew Adams]

> > See option `blink-matching-paren-distance' and node 
> > Matching in the Emacs manual.
> > Does increasing that variable's value resolve the problem?
> 
> Yes, it does solve the problem.

It's not real obvious when you see mismatch highlighting (and are used to it
working) that the highlighting might not mean a mismatch at all, but just an
insufficiently large option value. Many (most?) users will not even guess that
there is such an option.

Perhaps we could use a :help-echo property along with the mismatch highlight
face, pointing to the option?

bug#5122: Mismatched parentheses when dealing with huge buffercontent

[Deniz Dogan]

2009/12/5 Drew Adams <drew.adams@oracle.com>:
>> > See option `blink-matching-paren-distance' and node
>> > Matching in the Emacs manual.
>> > Does increasing that variable's value resolve the problem?
>>
>> Yes, it does solve the problem.
>
> It's not real obvious when you see mismatch highlighting (and are used to it
> working) that the highlighting might not mean a mismatch at all, but just an
> insufficiently large option value. Many (most?) users will not even guess that
> there is such an option.
>
> Perhaps we could use a :help-echo property along with the mismatch highlight
> face, pointing to the option?
>
>

I'm not sure what the best solution would be, but it is indeed strange
that Emacs says that there was a parenthesis *mismatch*. Maybe it
would be better to say something along the lines of "Emacs was unable
to find a matching parenthesis in the previous X characters", but
obviously much more terse.

bug#5122: Mismatched parentheses when dealing with huge buffercontent

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 4 Dec 2009 16:31:51 -0800
> Cc: emacs-pretest-bug@gnu.org, 5122@emacsbugs.donarmstrong.com
> 
> It's not real obvious when you see mismatch highlighting (and are used to it
> working) that the highlighting might not mean a mismatch at all, but just an
> insufficiently large option value. Many (most?) users will not even guess that
> there is such an option.
> 
> Perhaps we could use a :help-echo property along with the mismatch highlight
> face, pointing to the option?

help-echo is not guaranteed to be seen, and could be tricky when
there's an important message in the echo area (especially if the
help-echo itself is displayed in the echo area).  Also, it will not
work on a text terminal.

I think it's better to modify the echo area message, such that if
Emacs hits the blink-matching-paren-distance limit (as opposed to
hitting point-min), the message says something like

  Mismatched parentheses (within blink-matching-paren-distance)

bug#5122: Mismatched parentheses when dealing with huge buffercontent

[Drew Adams]

> > It's not real obvious when you see mismatch highlighting 
> (and are used to it
> > working) that the highlighting might not mean a mismatch at 
> all, but just an
> > insufficiently large option value. Many (most?) users will 
> not even guess that
> > there is such an option.
> > 
> > Perhaps we could use a :help-echo property along with the 
> mismatch highlight
> > face, pointing to the option?
> 
> help-echo is not guaranteed to be seen, and could be tricky when
> there's an important message in the echo area (especially if the
> help-echo itself is displayed in the echo area).  Also, it will not
> work on a text terminal.
> 
> I think it's better to modify the echo area message, such that if
> Emacs hits the blink-matching-paren-distance limit (as opposed to
> hitting point-min), the message says something like
> 
>   Mismatched parentheses (within blink-matching-paren-distance)

Yes that sounds good too.

To be honest, I don't know if I ever noticed any message in the echo area for
this. Perhaps because the message was so expected I never paid any attention to
it.

bug#5122: Mismatched parentheses when dealing with huge buffercontent

[Chong Yidong]

> I think it's better to modify the echo area message, such that if
> Emacs hits the blink-matching-paren-distance limit (as opposed to
> hitting point-min), the message says something like
>
>   Mismatched parentheses (within blink-matching-paren-distance)

Error messages shouldn't be so verbose---they can't spell out every bell
and whistle related to the error.  I prefer leaving things the way they
are.

bug#5122: Mismatched parentheses when dealing with huge buffercontent

[Stefan Monnier]

>> I think it's better to modify the echo area message, such that if
>> Emacs hits the blink-matching-paren-distance limit (as opposed to
>> hitting point-min), the message says something like
>> Mismatched parentheses (within blink-matching-paren-distance)
> Error messages shouldn't be so verbose---they can't spell out every bell
> and whistle related to the error.  I prefer leaving things the way they
> are.

But it should be less definitive: rather than just say authoritatively
"mismatched paren", it should at least be more humble and say "can't
find matching paren".


        Stefan

bug#5122: Mismatched parentheses when dealing with huge buffercontent

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> But it should be less definitive: rather than just say authoritatively
> "mismatched paren", it should at least be more humble and say "can't
> find matching paren".

"No matching paren found" sounds fine.

bug#5122: Mismatched parentheses when dealing with huge buffercontent

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: 5122@emacsbugs.donarmstrong.com
> Date: Sat, 05 Dec 2009 15:57:58 -0500
> 
> > I think it's better to modify the echo area message, such that if
> > Emacs hits the blink-matching-paren-distance limit (as opposed to
> > hitting point-min), the message says something like
> >
> >   Mismatched parentheses (within blink-matching-paren-distance)
> 
> Error messages shouldn't be so verbose---they can't spell out every bell
> and whistle related to the error.

I'd say adding a couple of words is hardly verbose, and certainly
isn't spelling out every detail.

> I prefer leaving things the way they are.

And leave users without a clue? how's that preferable?

bug#5122: Mismatched parentheses when dealing with huge buffercontent

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> Error messages shouldn't be so verbose---they can't spell out every bell
>> and whistle related to the error.
>
> I'd say adding a couple of words is hardly verbose, and certainly
> isn't spelling out every detail.
>
>> I prefer leaving things the way they are.
>
> And leave users without a clue? how's that preferable?

The circumstances in which the parenthesis are mismatched probably
vastly outweigh the circumstances in which the user wants to change
blink-matching-paren-distance.

So, it is arguably more confusing to the average user if the error
message mumbles something about blink-matching-paren-distance.  For
those who care, it's an apropos search away.

bug#5122: Mismatched parentheses when dealing with huge buffercontent

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: 5122@emacsbugs.donarmstrong.com
> Date: Sat, 05 Dec 2009 17:11:09 -0500
> 
> The circumstances in which the parenthesis are mismatched probably
> vastly outweigh the circumstances in which the user wants to change
> blink-matching-paren-distance.

I suggested the modified message text _only_ for those cases where the
search hits the limit.

bug#5122: Mismatched parentheses when dealing with huge buffercontent

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> The circumstances in which the parenthesis are mismatched probably
>> vastly outweigh the circumstances in which the user wants to change
>> blink-matching-paren-distance.
>
> I suggested the modified message text _only_ for those cases where the
> search hits the limit.

How do you distinguish this from the plain old "no mismatched
parenthesis" case?  Like I said, if there is no matching parenthesis
within the search limit (which, btw, has been increased in Emacs 22.3),
in most cases the parentheses really are mismatched.

bug#5122: Mismatched parentheses when dealing with huge buffercontent

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: 5122@emacsbugs.donarmstrong.com
> Date: Sun, 06 Dec 2009 10:30:37 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The circumstances in which the parenthesis are mismatched probably
> >> vastly outweigh the circumstances in which the user wants to change
> >> blink-matching-paren-distance.
> >
> > I suggested the modified message text _only_ for those cases where the
> > search hits the limit.
> 
> How do you distinguish this from the plain old "no mismatched
> parenthesis" case?

Sorry, I don't understand the question.  What is the "no mismatched
parenthesis" case?

To clarify, my suggestion was to display

  Mismatched parenthesis

if the search hits point-min or point-max without finding a match, or

  Mismatched parenthesis (within blink-matching-paren-distance)

if the search doesn't find a match within
blink-matching-paren-distance.

> Like I said, if there is no matching parenthesis within the search
> limit (which, btw, has been increased in Emacs 22.3), in most cases
> the parentheses really are mismatched.

But we don't know that, unless we searched all the way to the
beginning or end of the buffer.  All we know is that we didn't find a
match within the distance searched.

bug#5122: Mismatched parentheses when dealing with huge buffercontent

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> Like I said, if there is no matching parenthesis within the search
>> limit (which, btw, has been increased in Emacs 22.3), in most cases
>> the parentheses really are mismatched.
>
> But we don't know that, unless we searched all the way to the
> beginning or end of the buffer.  All we know is that we didn't find a
> match within the distance searched.

I understand what you're saying.  But even if there is a "matching"
paren more than 102k characters away (the blink-matching-paren-distance
default), chances are that's a mistake anyway.

Yes, I know the failure condition exists.  But for every user
enlightened by a more verbose error message, I think there will be
hundreds more that will be unnecessarily confused.

bug#5122: Mismatched parentheses when dealing with huge buffercontent

[Stefan Monnier]

>> I prefer leaving things the way they are.
> And leave users without a clue? how's that preferable?

Clearly, the only real answer is to get rid of
blink-matching-paren-distance.  We could try and do that, maybe using
while-no-input.


        Stefan

bug#5122: Mismatched parentheses when dealing with huge buffercontent

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I prefer leaving things the way they are.
>> And leave users without a clue? how's that preferable?
>
> Clearly, the only real answer is to get rid of
> blink-matching-paren-distance.  We could try and do that, maybe using
> while-no-input.

That would be a good long-term solution.

Meanwhile, I've implemented Eli's suggestion of just altering the
message to add " within the limit" if we're limited.  So I'm closing
this bug report.

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

bug#5122: Mismatched parentheses when dealing with huge buffercontent

[Drew Adams]

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >>> I prefer leaving things the way they are.
> >>
> >> And leave users without a clue? how's that preferable?
> >
> > Clearly, the only real answer is to get rid of
> > blink-matching-paren-distance.  We could try and do that, 
> > maybe using while-no-input.
> 
> That would be a good long-term solution.
> 
> Meanwhile, I've implemented Eli's suggestion of just altering the
> message to add " within the limit" if we're limited.  So I'm closing
> this bug report.

Stefan says what "clearly, the only real answer" is.
He says that can be tried, and he makes a suggestion how.

So why, if that is clearly the answer, do you close the bug?

Makes no sense.  Is the goal just to close bugs or to fix the problem?

Is someone getting paid by the bug closure or something? ;-)

bug#5122: Mismatched parentheses when dealing with huge buffercontent

[Drew Adams]

> Stefan says what "clearly, the only real answer" is.
> He says that can be tried, and he makes a suggestion how.
> 
> So why, if that is clearly the answer, do you close the bug?
> Makes no sense.  Is the goal just to close bugs or to fix the problem?
> Is someone getting paid by the bug closure or something? ;-)

And why close it as `fixed' if Emacs Dev will not fix it?
The problem reported is still there, AFAIK.  Why not `wontfix'?

bug#5122: Mismatched parentheses when dealing with huge buffercontent

[MON KEY]

For really large groups of parens of type `mismatch-maybe' would it be
possible/reasonable/faster to do a check/balance to the nearest pair
of parens relative
the first 10 Catalan numbers e.g. something like this (or his brethren):

(URL `http://www2.research.att.com/~njas/sequences/A000108')
(URL `http://www2.research.att.com/~njas/sequences/table?a=108&fmt=4')

--
s_P