unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Chong Yidong'" <cyd@stupidchicken.com>,
	<5122@emacsbugs.donarmstrong.com>,
	"'Eli Zaretskii'" <eliz@gnu.org>
Subject: bug#5122: Mismatched parentheses when dealing with hugebuffercontent
Date: Sun, 6 Dec 2009 11:23:46 -0800	[thread overview]
Message-ID: <03D8B9F59D244FBE9F56B166B741AB56@us.oracle.com> (raw)
In-Reply-To: <87my1w0vzt.fsf@stupidchicken.com>

> >> 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	other threads:[~2009-12-06 19:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-05 20:57 bug#5122: Mismatched parentheses when dealing with huge buffercontent Chong Yidong
2009-12-05 21:42 ` Stefan Monnier
2009-12-05 22:06   ` Chong Yidong
2009-12-05 21:47 ` Eli Zaretskii
2009-12-05 22:11   ` Chong Yidong
2009-12-06  2:08     ` bug#5122: Mismatched parentheses when dealing with hugebuffercontent Drew Adams
2009-12-06 15:15       ` Drew Adams
2009-12-06 19:13       ` Chong Yidong
2009-12-06 20:57         ` Drew Adams
2009-12-06  4:03     ` bug#5122: Mismatched parentheses when dealing with huge buffercontent Eli Zaretskii
2009-12-06 15:30       ` Chong Yidong
2009-12-06 17:05         ` bug#5122: Mismatched parentheses when dealing with hugebuffercontent Drew Adams
2009-12-06 17:52         ` bug#5122: Mismatched parentheses when dealing with huge buffercontent Eli Zaretskii
2009-12-06 18:59           ` Chong Yidong
2009-12-06 19:23             ` Drew Adams [this message]
2009-12-07  2:25   ` Stefan Monnier
2011-07-13 14:59     ` Lars Magne Ingebrigtsen
2011-07-13 16:35       ` Drew Adams
2011-07-13 17:26       ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=03D8B9F59D244FBE9F56B166B741AB56@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=5122@emacsbugs.donarmstrong.com \
    --cc=cyd@stupidchicken.com \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).