bug#15670: 24.3; dummy user-errors on info nodes without prev/next nodes

[Drew Adams <drew.adams@oracle.com>]

> 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=11999#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-error'
 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 that.)

 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 replacement.
 This kind of change requires time, analysis, & judgment.  The person making 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 perhaps
 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 `error'
 or `user-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, ...).

 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 author
 >> 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.)