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#11999: 24.1.50; New Info file suffix ".info" breaks `Info-find-node-2' Date: Mon, 23 Jul 2012 06:54:50 -0700 Message-ID: References: <30361DAB51FE4AC487EBA7C11AACB36C@us.oracle.com><831uk688pk.fsf@gnu.org><35D365A3D0D0487CB7928FB2A672541D@us.oracle.com><83sjcl7b5w.fsf@gnu.org> <83eho325d9.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1343051755 29838 80.91.229.3 (23 Jul 2012 13:55:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 23 Jul 2012 13:55:55 +0000 (UTC) Cc: 11999@debbugs.gnu.org To: "'Stefan Monnier'" , "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jul 23 15:55:50 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1StJ6t-0000RG-BF for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Jul 2012 15:55:43 +0200 Original-Received: from localhost ([::1]:57659 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StJ6s-0006Dq-Pe for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Jul 2012 09:55:42 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43830) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StJ6k-00068a-Op for bug-gnu-emacs@gnu.org; Mon, 23 Jul 2012 09:55:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1StJ6e-0005nz-NZ for bug-gnu-emacs@gnu.org; Mon, 23 Jul 2012 09:55:34 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51220) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StJ6e-0005nv-Jz for bug-gnu-emacs@gnu.org; Mon, 23 Jul 2012 09:55:28 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1StJD0-0005Mn-80 for bug-gnu-emacs@gnu.org; Mon, 23 Jul 2012 10:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 23 Jul 2012 14:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11999 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11999-submit@debbugs.gnu.org id=B11999.134305210720610 (code B ref 11999); Mon, 23 Jul 2012 14:02:02 +0000 Original-Received: (at 11999) by debbugs.gnu.org; 23 Jul 2012 14:01:47 +0000 Original-Received: from localhost ([127.0.0.1]:60766 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StJCl-0005MM-6S for submit@debbugs.gnu.org; Mon, 23 Jul 2012 10:01:47 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:47802) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StJCh-0005ME-S4 for 11999@debbugs.gnu.org; Mon, 23 Jul 2012 10:01:45 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6NDt7eJ012693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jul 2012 13:55:08 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6NDt6lb008712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2012 13:55:07 GMT Original-Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6NDt6HX004880; Mon, 23 Jul 2012 08:55:06 -0500 Original-Received: from dradamslap1 (/10.159.218.129) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Jul 2012 06:55:06 -0700 X-Mailer: Microsoft Office Outlook 11 In-reply-to: Thread-Index: Ac1osJlae7VswWeIRCKVIrVy5uvbRgAJmv4g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:62308 Archived-At: > > What about an error condition that is neither of these two? Or are > > you saying that an error must be one of these two, and nothing else? > > Either you get a backtrace, or you don't. Currently, there's no > in-between choice, so there are only two possibilities. For now then, one of the two should be defined clearly and operationally (i.e., easy to understand and distinguish). And the other should be defined as the complement. If we add more cases in the future, we should continue to keep one case as "otherwise". Probably `error' should be that fallback (always). > > But it isn't a user error, either. Perhaps we should find a better > > name for that, as long as it isn't too late. > > Since it hasn't yet been released, it's not too late to change. > And since it's only visible to the Elisp programmer, its name does not > matter that much. The name and the definition are important precisely because it is visible to Elisp programmers. It is they who create the effective meaning, by putting the name and definition (= a spec) into practice, i.e., by defining real behavior. And this bug report (including the part about an apparent wholesale replacement of `error' in info.el) is a good example of the importance of getting the name & definition right. Whatever this new case is that we are carving out from the formerly single catchall, `error', it should be defined clearly, so that it is used accordingly. It should be made clear (via the doc) to Elisp programmers (starting with Emacs Dev) that the new error function should be used only when its specific defining characteristics hold, and that `error' should be used otherwise (always). > I.e. I'm open to suggestions, but I don't think it's worth > spending too much time on it. I will try to help with the name, once you make clear what the defining characteristics are: in what cases should this be used? Whatever is not included in those characteristics should fall to plain `error'. IOW, do not try to define both the new function and `error' explicitly (risk of contradiction/overlap, gaps) - define the new one, and define `error' as the complement: all other error cases. No junk, no confusion. What should not be done is what has been done so far: define two categories that leave a gap between them or that overlap. Try to make the definition of the new function clear and simple, and state explicitly in the doc that if its qualifying conditions do not apply then use `error'. That will help ensure that programmers implement that spec correctly and so end up realizing the intended behavior in practice.