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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 11999 <at> debbugs.gnu.org
Subject: bug#11999: 24.1.50; New Info file suffix ".info" breaks `Info-find-node-2'
Date: Sat, 21 Jul 2012 11:47:55 +0300

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <schwab <at> linux-m68k.org>, <11999 <at> debbugs.gnu.org>
> Date: Fri, 20 Jul 2012 14:08:07 -0700
> 
> > You will need to explain more, because info-insert-file-contents first
> > tests for the argument FILENAME, and if that does not exist, it tries
> > FILENAME with every extension in Info-suffix-list, which includes
> > ".info".
> > 
> > In particular, this works for me on MS-Windows:
> >   M-: (info-insert-file-contents "d:/path/to/emacs/info/emacs") RET
> > and loads emacs.info.  Why doesn't it work for you?
> 
> My bad.  The difference turned out to be the use now of `user-error' instead of
> `error'.  Where I previously just saw a message saying there was no such node,
> now Emacs puts me in the debugger, because I have non-nil `debug-on-error'.

So how is one supposed to avoid entering the debugger on user-error,
when debug-on-error is non-nil?

> Going only by the doc string of `user-error', it seems that at least some of the
> many changes from `error' to `user-error' in info.el (and beyond?) are
> inappropriate.

The doc string IMO does not tell enough, and there's no other
documentation about user-error, neither in the ELisp manual nor in
NEWS (which only mentions its existence).

Stefan, could you perhaps provide some insight?  What is a "pilot
error" in this context, and how should Lisp programs use this new
facility to (supposedly) provide better diagnostics and/or better
error handling?

> An index lookup of a term that is not in the index is in general NOT a "pilot
> error".  It is normal behavior on the part of users to look up terms in the
> index, whether they happen to be there or not.

I agree.  But then it's unclear to me whether using 'error' in this
case would be better.  If you think it is, please tell why.

> An index lookup that finds no hit is NOT "expected to be the result of an
> incorrect manipulation on the part of the user, rather than the result of an
> actual problem." 

Agree again, but again unsure how 'error' would be better.  Maybe we
need yet a 3rd kind of errors?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.