From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#5122: Mismatched parentheses when dealing with hugebuffercontent Date: Sun, 6 Dec 2009 11:23:46 -0800 Message-ID: <03D8B9F59D244FBE9F56B166B741AB56@us.oracle.com> References: <87ocmdw33d.fsf@stupidchicken.com> <838wdhjdpj.fsf@gnu.org><87d42trs02.fsf@stupidchicken.com> <83638kkau1.fsf@gnu.org><878wdgw25e.fsf@stupidchicken.com> <833a3oj8gv.fsf@gnu.org> <87my1w0vzt.fsf@stupidchicken.com> Reply-To: Drew Adams , 5122@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1260128882 28805 80.91.229.12 (6 Dec 2009 19:48:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 6 Dec 2009 19:48:02 +0000 (UTC) To: "'Chong Yidong'" , <5122@emacsbugs.donarmstrong.com>, "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 06 20:47:55 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NHN5F-00089K-Bm for geb-bug-gnu-emacs@m.gmane.org; Sun, 06 Dec 2009 20:47:53 +0100 Original-Received: from localhost ([127.0.0.1]:45849 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHN5F-0007Hv-3D for geb-bug-gnu-emacs@m.gmane.org; Sun, 06 Dec 2009 14:47:53 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHN51-0007D5-3c for bug-gnu-emacs@gnu.org; Sun, 06 Dec 2009 14:47:39 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHN4w-0007CF-FZ for bug-gnu-emacs@gnu.org; Sun, 06 Dec 2009 14:47:38 -0500 Original-Received: from [199.232.76.173] (port=43906 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHN4w-0007C1-2H for bug-gnu-emacs@gnu.org; Sun, 06 Dec 2009 14:47:34 -0500 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:54911) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NHN4v-0003cI-D3 for bug-gnu-emacs@gnu.org; Sun, 06 Dec 2009 14:47:33 -0500 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nB6JlPCC005214; Sun, 6 Dec 2009 11:47:31 -0800 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id nB6JU5e7003092; Sun, 6 Dec 2009 11:30:05 -0800 Resent-Date: Sun, 6 Dec 2009 11:30:05 -0800 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Sun, 06 Dec 2009 19:30:05 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 5122 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 5122-submit@emacsbugs.donarmstrong.com id=B5122.12601274892327 (code B ref 5122); Sun, 06 Dec 2009 19:30:05 +0000 Original-Received: (at 5122) by emacsbugs.donarmstrong.com; 6 Dec 2009 19:24:49 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nB6JOlqb002318 for <5122@emacsbugs.donarmstrong.com>; Sun, 6 Dec 2009 11:24:48 -0800 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nB6JOVPn017576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 6 Dec 2009 19:24:32 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nB6J2Ida031191; Sun, 6 Dec 2009 19:24:52 GMT Original-Received: from abhmt010.oracle.com by acsmt355.oracle.com with ESMTP id 828365421260127417; Sun, 06 Dec 2009 11:23:37 -0800 Original-Received: from dradamslap1 (/24.5.185.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 06 Dec 2009 11:23:36 -0800 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp2p2We9NrLyaW3Q5eDJVkTNNR6ggAAHzow In-Reply-To: <87my1w0vzt.fsf@stupidchicken.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4B1C04F6.0009:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Sun, 06 Dec 2009 14:47:38 -0500 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:33328 Archived-At: > >> 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.