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: Sat, 5 Dec 2009 18:08:08 -0800 Message-ID: <7CFBD14168FC4B1389C926E26A54B9E1@us.oracle.com> References: <87ocmdw33d.fsf@stupidchicken.com> <838wdhjdpj.fsf@gnu.org> <87d42trs02.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 1260066469 16325 80.91.229.12 (6 Dec 2009 02:27:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 6 Dec 2009 02:27:49 +0000 (UTC) Cc: deniz.a.m.dogan@gmail.com 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 03:27:41 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 1NH6qb-00052W-45 for geb-bug-gnu-emacs@m.gmane.org; Sun, 06 Dec 2009 03:27:41 +0100 Original-Received: from localhost ([127.0.0.1]:59749 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NH6qa-0002Mq-9u for geb-bug-gnu-emacs@m.gmane.org; Sat, 05 Dec 2009 21:27:40 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NH6qV-0002MT-MQ for bug-gnu-emacs@gnu.org; Sat, 05 Dec 2009 21:27:35 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NH6qQ-0002Lt-5E for bug-gnu-emacs@gnu.org; Sat, 05 Dec 2009 21:27:34 -0500 Original-Received: from [199.232.76.173] (port=48132 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NH6qP-0002Lq-SV for bug-gnu-emacs@gnu.org; Sat, 05 Dec 2009 21:27:29 -0500 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:50883) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NH6qP-0004i4-Dp for bug-gnu-emacs@gnu.org; Sat, 05 Dec 2009 21:27:29 -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 nB62RPCg005271; Sat, 5 Dec 2009 18:27:27 -0800 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id nB62F8rD003954; Sat, 5 Dec 2009 18:15:08 -0800 Resent-Date: Sat, 5 Dec 2009 18:15:08 -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 02:15:08 +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.12600653903109 (code B ref 5122); Sun, 06 Dec 2009 02:15:08 +0000 Original-Received: (at 5122) by emacsbugs.donarmstrong.com; 6 Dec 2009 02:09:50 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nB629mO9003106 for <5122@emacsbugs.donarmstrong.com>; Sat, 5 Dec 2009 18:09:49 -0800 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nB629XEX023992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 6 Dec 2009 02:09:35 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nB61MtDE002765; Sun, 6 Dec 2009 02:09:45 GMT Original-Received: from abhmt003.oracle.com by acsmt357.oracle.com with ESMTP id 823407451260065280; Sat, 05 Dec 2009 20:08:00 -0600 Original-Received: from dradamslap1 (/24.5.185.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 05 Dec 2009 18:07:59 -0800 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp1+kX9eaGk8tcDTqSBd3CAU1vVYwAFc9RQ In-Reply-To: <87d42trs02.fsf@stupidchicken.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4B1B1263.00CD:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Sat, 05 Dec 2009 21:27:34 -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:33303 Archived-At: > >> 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? Eli is right. It is plain poor judgment to leave things the way they are in this case. > The circumstances in which the parenthesis are mismatched probably > vastly outweigh the circumstances in which the user wants to change > blink-matching-paren-distance. That's one point, sure. But the opposing consideration is how much damage occurs when the problem, rare though it might be, does arise. When a false mismatch occurs, the user has no clue - truly no clue - as to what is going on. (This is in fact truer the rarer the event is!) I know this because it happened to me. That's why I was able to respond to Deniz's bug report so quickly. I just went through the same thing a month or so back. (And yes, I had already known this years ago, but had forgotten - perhaps because of the rarity. I was looking at code from someone else (BBDB), which uses much larger function definitions than I do.) I spent quite a bit of time trying, in vain, to figure out what the problem was with the code (e.g. an unescaped left paren in col 1 of a doc string, escape sequences in regexp strings,...). And that's the point, the opposing consideration: the difficulty and improbability of finding the explanation/solution. One's reflex is not to suppose that this is normal behavior governed by some user option. Believe me. The tendency is to try to find out what is causing the mismatch. No one spontaneously doubts that there is a mismatch. This is very different from some other limits we have in Emacs. When a buffer is bigger than the default font-locking buffer size, you can tell: there simply is no font-locking. So if you're ignorant of the cause/remedy in that case, you naturally search for something having to do with font-locking - you can tell that there is a font-locking problem. You search a bit, and you eventually find `font-lock-fontify-buffer' and solve the problem. But here the natural inclination is to assume, since there is mismatch highlighting, that there is, well, a mismatch. Duh. I said the user has no clue as to what's going on in this situation. But it's actually worse than that. We lead the user down the garden path. We say, in effect, "Look over there! (without saying where)". Gotcha! Look all you want over there, but there is nothing to find. The problem is right here. It lies with the messenger who's telling you to look over there. The paren-mismatch-highlighting code itself _knows_ when it has reached its limit (or it should know), so it _knows_ when its highlighting no longer makes any sense and can only mislead. It is up to that code to DTRT and - at a minimum - do nothing in this context; do no harm. Better would be for it to signal explicitly that it has gone beyond its limit. > 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. You seem to have an interesting understanding of what is confusing to users, average or otherwise. And I couldn't disagree more about the ease of finding the problem, "for those who care". To find it, you need to be looking for it. You need to have some idea of what is going on, some idea that the paren highlighting is not functioning normally and its helpful indicator should not be trusted. You need some hint that you should look for an option concerning parens. When you see mismatch highlighting, you do not assume that something is wrong with the highlighting (or that some limit has been surpassed for its normal functioning). You assume instead that there is in fact a mismatch somewhere. _You trust what Emacs tells you._ Imagine if compiler error messages showed up spuriously, incorrectly, whenever some esoteric threshold was surpassed - a setting that you didn't even know about. Would you even think to look for such a setting? Or would you instead, naturally, believe the compiler error message and dive into a close examination of your code to try to understand its problem. Yes, you would look over there... Emacs is misleading users in this situation. It is staring up at the top of a building, causing others to look up also, even though there is nothing to see there. If you are really worried about the intrusiveness of an explanation in the echo message or in a tooltip (remember, the mouse would need to be over the "mismatched" paren for the tooltip message to appear, and the message would only need to be displayed when the threshold is in fact surpassed), then consider simply _not highlighting_ at all whenever the search distance has been exceeded. Turning off highlighting in this case would at least clue the user to look for something having to do with paren highlighting. What is bad design ("confusing to the average user") is blindly signaling an error (mismatch) when the measuring tool knows (or should know) that it is currently incapable of measuring at all! [Also, this option/feature should not necessarily be called "blink" anything, or at least an alias should be provided, so that it would be easier to find for those who use `show-paren-mode'. If one uses paren highlighting, then this is more obviously about paren highlighting than paren blinking.]