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#15670: 24.3; dummy user-errors on info nodes without prev/next nodes Date: Mon, 21 Oct 2013 09:43:05 -0700 (PDT) Message-ID: <4235086e-f6e7-4479-babc-261b464152ee@default> References: <526548F4.3040601@poczta.onet.pl> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1382373862 2074 80.91.229.3 (21 Oct 2013 16:44:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2013 16:44:22 +0000 (UTC) To: Jarek Czekalski , 15670@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 21 18:44:26 2013 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 1VYIac-00040P-O3 for geb-bug-gnu-emacs@m.gmane.org; Mon, 21 Oct 2013 18:44:23 +0200 Original-Received: from localhost ([::1]:40814 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYIac-0000R1-AX for geb-bug-gnu-emacs@m.gmane.org; Mon, 21 Oct 2013 12:44:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43635) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYIaS-0000Qt-NI for bug-gnu-emacs@gnu.org; Mon, 21 Oct 2013 12:44:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VYIaI-0006X9-WE for bug-gnu-emacs@gnu.org; Mon, 21 Oct 2013 12:44:12 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47018) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYIaI-0006X4-SU for bug-gnu-emacs@gnu.org; Mon, 21 Oct 2013 12:44:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VYIaI-0004eK-CH for bug-gnu-emacs@gnu.org; Mon, 21 Oct 2013 12:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Oct 2013 16:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15670 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15670-submit@debbugs.gnu.org id=B15670.138237380717816 (code B ref 15670); Mon, 21 Oct 2013 16:44:02 +0000 Original-Received: (at 15670) by debbugs.gnu.org; 21 Oct 2013 16:43:27 +0000 Original-Received: from localhost ([127.0.0.1]:32803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VYIZi-0004dH-NC for submit@debbugs.gnu.org; Mon, 21 Oct 2013 12:43:27 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:22497) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VYIZg-0004cz-Ay for 15670@debbugs.gnu.org; Mon, 21 Oct 2013 12:43:25 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9LGhGGw009045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Oct 2013 16:43:17 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9LGhEQ2017742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Oct 2013 16:43:16 GMT Original-Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9LGhEPl014441; Mon, 21 Oct 2013 16:43:14 GMT In-Reply-To: <526548F4.3040601@poczta.onet.pl> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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:79460 Archived-At: > Expected behaviour: no user-errors should be generated, when user > makes no errors. Here's the problem: For Emacs Dev, a regular (i.e., non-user) "error" means something is wrong with the program itself or something unexpected happened, such as a disk problem. "User error" is more or less left as a catch-all, for behavior that the program expects. Emacs provides for such a "user" error by ending the dialog with an error message - it is one step beyond just calling `message' and ending the current command. The name `user-error' thus does not really correspond to pilot error. This is what the doc says about `user-error': "[It is] intended to report errors on the part of the user, rather than errors in the code itself." Or as Stefan put it, a user error is "A error of the user rather than of the author of the code." As almost anyone can tell, this is a false dichotomy. An error does not necessarily fall into one of those two camps. And that is the explanation for what you are seeing: Because the error you reported is not considered to be an "error in the code itself", by process of elimination it is considered to be a "user error". Which of course it is not, really. The doc continues with an example which is very close to the one you cited: For example, if you try to use the command `Info-history-back' (`l') to move back beyond the start of your Info browsing history, Emacs signals a `user-error'. And then the doc gives you the _real_ difference, in terms not of name or described meaning, but of what the _behavior_ is: Such errors do not cause entry to the debugger, even when `debug-on-error' is non-`nil'. That's the real difference. Should the error you cite cause entry to the debugger? That's the only question to be posed here. If so then `user-error', in spite of the unfortunate name, is appropriate. This should have been called a different name that reflects the real meaning, and the description not should say anything about "user error" or "errors on the part of the user". This was all discussed at the time `user-error' was added. We are living with that decision. Here is the discussion thread: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D11999#35. Highlights: "[In] this particular use case (and perhaps others? it seems that `error' was nearly systematically replaced with `user-error' in info.el) is inappropriate. At least according to the stated purpose of `user-error' - this is not at all "pilot error"." "[W]hat do you think is the correct way to signal to a user that the term s?he tried to look up is not= in the index? Is it `message'? `message' + `ding'? `error' (as always, previously)? `user-error'? something else? If it is `user-error' then I think the doc needs to be changed to correct = the stated aim of `user-error'. If it is not `user-error' then maybe the code= needs to be checked generally for additional places where the purpose of `user-e= rror' might not have been respected." "(Most (>99%) uses of `error' have had nothing to do with trying to signal = a problem of the code itself. IOW, `error' is not used often just for this-should-never-happen errors (debugging). But that's the impression I = get from the `user-error' doc: that `user-error' is not intended to signal a programming problem, which suggests that `error' might be intended for tha= t.) Two things matter: (1) what the actual behavior is in a given context, and whether it is useful/appropriate, (2) what the stated use of `user-error' = is, and whether actual uses correspond to it. To me, #1 is generally more important." "It _looks_ (with just a glance) like someone blanket-replaced `error' with `user-error' in info.el (and elsewhere?). That cannot be right, _if_ the = stated purpose of `user-error' is correct." "And perhaps other files were also subjected to such a wholesale replacemen= t. This kind of change requires time, analysis, & judgment. The person makin= g the change at any given occurrence needs to read, understand the code, and (especially) think of the user." "[T]hat description is a false, binary choice. The same false choice is presented by "A error of the user rather than of the author of the code." = There are uses of error signaling (and more generally, alerting the user and per= haps returning to top level) that are neither. IOW, there is a lot that is neither an error by the user nor a mistake in = the code. Without clarifying the doc & design wrt this middle ground, we will continue to (a) confuse users and (b) have inappropriate uses of either `e= rror' or `user-error'." "> I already explained it: user-error is for errors which are=20 > not caused by bugs in the code (i.e. they're caused by > manipulation mistakes, or problems in the environment such > as missing files, ...). 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. Given that approach, I would propose these names: * `code-error': errors that indicate a bug in the code * `other-error': any other error" ">> >> Note that most uses of `user-error' are correct in that they signal >> >> conditions which are usually simply due to a mistaken manipulation >> >> (such as trying to move past the EOB) >> > >> > That's a coincidence: we tend to want the no-debug behavior for user >> > errors. Bu the feature is not about user errors, it's about not >> > entering the debugger. >> >> No, it's not just a coincidence: if the problem is not due to the autho= r >> of the code having made a mistake, then it can basically only be due to >> a mistake of the user in its larger sense (which includes the steps the >> user or his sysadmin did to set up the system). > > Let's take the use case of typing "i foobar" and getting "No 'foobar' > in index." in response. Whose fault/mistake is this? I think it is clearly a "user error. - Stefan" "I give up. - Eli" (Drew gave up sometime before that point.)