bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#5122: Mismatched parentheses when dealing with hugebuffercontent


From: Drew Adams
Subject: bug#5122: Mismatched parentheses when dealing with hugebuffercontent
Date: Sun, 6 Dec 2009 11:23:46 -0800

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

Why would that be true any more than if the limit were 300 chars instead of
102k? The matching code works to the same degree, no matter what the limit is.
Either the matching code is accurate, or it is not, but the limit used has no
bearing on that.

The cases where what we are asking for is needed are real cases where large
function definitions (or other large lists in code) exist. The code is not a
"mistake", even if it might be poor style. What is a mistake is to report a
paren mismatch when there is no mismatch.

No one has yet pointed to any case where the matching code has shown a false
positive, claiming a mismatch where there isn't any - except when the search is
limited, which is precisely the case in question. We can and do rely on the
accuracy of mismatch reporting, when the search is not prematurely ended by the
limit. It works well. Do you have some reason to doubt it?

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

Why would anyone be confused by a message saying that the search limit was
reached? 

Turning off the mismatch highlighting in this case, and displaying the help
buffer for the limit option (with its link to Customize), would dispel any
possible confusion about what is happening.

Massive confusion arises currently, though, by incorrectly showing mismatch
highlighting when there is no mismatch. That completely disorienting confusion
occurs with _exactly_ the same frequency as would the message that (only) you
think would be confusing. This situation is rare. But it is important (yes, for
the average user) to help, not hurt, when it does arise.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]