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 18:30:38 -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 1343093491 13223 80.91.229.3 (24 Jul 2012 01:31:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 Jul 2012 01:31:31 +0000 (UTC) Cc: 11999@debbugs.gnu.org To: "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 24 03:31:30 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 1StTyD-000423-5I for geb-bug-gnu-emacs@m.gmane.org; Tue, 24 Jul 2012 03:31:29 +0200 Original-Received: from localhost ([::1]:57753 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StTyC-0002aY-HM for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Jul 2012 21:31:28 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StTyA-0002aT-KN for bug-gnu-emacs@gnu.org; Mon, 23 Jul 2012 21:31:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1StTy9-0007G6-7U for bug-gnu-emacs@gnu.org; Mon, 23 Jul 2012 21:31:26 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52964) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StTy9-0007G2-4I for bug-gnu-emacs@gnu.org; Mon, 23 Jul 2012 21:31:25 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1StU4X-0004g9-OR for bug-gnu-emacs@gnu.org; Mon, 23 Jul 2012 21:38:01 -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: Tue, 24 Jul 2012 01:38:01 +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.134309384517832 (code B ref 11999); Tue, 24 Jul 2012 01:38:01 +0000 Original-Received: (at 11999) by debbugs.gnu.org; 24 Jul 2012 01:37:25 +0000 Original-Received: from localhost ([127.0.0.1]:34277 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StU3w-0004dY-Ph for submit@debbugs.gnu.org; Mon, 23 Jul 2012 21:37:25 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:44420) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StU3u-0004dE-2r for 11999@debbugs.gnu.org; Mon, 23 Jul 2012 21:37:22 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6O1UgpC027552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jul 2012 01:30:43 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6O1Ufas006566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jul 2012 01:30:42 GMT Original-Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6O1UfH3030130; Mon, 23 Jul 2012 20:30:41 -0500 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Jul 2012 18:30:40 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac1pKtxZGbF0JyuvSTOnZ+xrCzYnmwAD+HLg X-Source-IP: ucsinet22.oracle.com [156.151.31.94] 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:62335 Archived-At: > > 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'. > > I already explained it: user-error is for errors which are > not caused by bugs in the code (i.e. they're caused by > manipulation mistakes, or problems in the environment such > as missing files, ...). I see. So it is instead the behavior of `error' that you are defining in a clear way, and `user-error' that is the catchall: everything else. I think that is a mistake, for the reason I gave earlier: If you need later to carve out a new class, it logically would come from the catch-all, which according to your classification is what you have called `user-error': anything that is not a code error. It makes much more sense, IMHO, for `error' to be the catchall. But you're the boss. Given that approach, I would propose these names: * `code-error': errors that indicate a bug in the code * `other-error': any other error `code-error' errors should presumably never happen. That is, we normally try to implement code that we do not _expect_ will ever throw a `code-error' error. Given such a renaming, you need to decide how to handle the traditional `error'. Would it be defaliased to `code-error', thus limiting the traditional scope considerably, or defaliased to `other-error', which is more in line with what it has been. IOW, given your characterization, I do not think it is a narrow category of "user" error that is new. What is new, it seems to me, is the narrow category of code errors. HTH.