bug#11999: 24.1.50; New Info file suffix ".info" breaks `Info-find-node-2'

[Drew Adams]

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