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

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

[Jarek Czekalski]

When viewing info pages user-errors are generated. I believe they should
not be there. This is a backtrace:

   signal(user-error ("Node has no Next"))
   user-error("Node has no %s" "Next")
   ad-Orig-Info-extract-pointer("next" nil)
   Info-extract-pointer("next")
   Info-check-pointer("next")
   redisplay_internal\ \(C\ function\)()

It's enough to start the info with C-h C-h r or C-h i to
make it happen.

Expected behaviour: no user-errors should be generated, when user makes
no errors.

This was seen when running Emacspeak on Windows.
Dummy error messages cause it to
stop speaking. The log was obtained by putting a backtrace in dtk-stop 
function.


In GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601)
  of 2013-03-17 on MARVIN
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
  `configure --with-gcc (4.7) --cflags
  -ID:/devel/emacs/libs/libXpm-3.5.8/include
  -ID:/devel/emacs/libs/libXpm-3.5.8/src
  -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
  -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
  -ID:/devel/emacs/libs/giflib-4.1.4-1/include
  -ID:/devel/emacs/libs/jpeg-6b-4/include
  -ID:/devel/emacs/libs/tiff-3.8.2-1/include
  -ID:/devel/emacs/libs/gnutls-3.0.9/include
  -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
  -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'

Important settings:
   value of $LANG: pl
   locale-coding-system: cp1250
   default enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
   global-hl-line-mode: t
   recentf-mode: t
   tooltip-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <down-mouse-1>
<mouse-1> <down-mouse-1> <mouse-1> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> M-x
r e p o <tab> r t - e m <tab> <return>

Recent messages:
[yas] Prepared just-in-time loading for 
c:/Users/Jarek/AppData/Roaming/.emacs.d/packages/snippets
[yas] Discovered there was already *scratch* in fundamental-mode
[yas] Loading compiled snippets from 
c:/Users/Jarek/AppData/Roaming/.emacs.d/snippets/fundamental-mode
[yas] Prepared just-in-time loading for ~/.emacs.d/snippets
[yas] Reloaded everything (snippets will load just-in-time)....
Loading hl-line...done
Loading whitespace...done
Loading grep...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils grep compile comint ansi-color ring whitespace
hl-line cus-start cus-load yasnippet derived easy-mmode edmacro kmacro
help-mode folding-isearch folding cl-macs gv advice help-fns
advice-preload recentf tree-widget wid-edit easymenu cl cl-lib server
time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel dos-w32
ls-lisp w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment lisp-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process w32 multi-tty emacs)
*** E-Mail body has been placed on clipboard, please paste it here! ***

bug#15670: how advised

[Jarek Czekalski]

Since I was not conscious of the advice, here is the advising used, I 
believe it has no influence on the bug:

;;; There is a bug in Emacs 21 that causes info-extract-pointer to be
;;; called erroneously.

(defadvice Info-extract-pointer  (around emacspeak pre act comp)
   "Silence emacspeak during call."
   (let ((emacspeak-speak-messages nil)
         (emacspeak-use-auditory-icons nil))
     ad-do-it))

Somehow this workaround does not work around, but that's a different 
tale. Let's fix a bug if there is a bug in Info.

Jarek

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

[Drew Adams]

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

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

[Stefan Monnier]

>   signal(user-error ("Node has no Next"))
>   user-error("Node has no %s" "Next")
>   ad-Orig-Info-extract-pointer("next" nil)
>   Info-extract-pointer("next")
>   Info-check-pointer("next")
>   redisplay_internal\ \(C\ function\)()

> It's enough to start the info with C-h C-h r or C-h i to
> make it happen.

> Expected behaviour: no user-errors should be generated, when user makes
> no errors.

Hmm... indeed, but Info-check-pointer catches all errors:

   (defun Info-check-pointer (item)
     "Non-nil if ITEM is present in this node."
     (condition-case nil
         (Info-extract-pointer item)
       (error nil)))

so that should silence this user-error.
What am I missing?


        Stefan

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

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >   signal(user-error ("Node has no Next"))
> >   user-error("Node has no %s" "Next")
> >   ad-Orig-Info-extract-pointer("next" nil)
> >   Info-extract-pointer("next")
> >   Info-check-pointer("next")
> >   redisplay_internal\ \(C\ function\)()
>
> > It's enough to start the info with C-h C-h r or C-h i to
> > make it happen.
>
> > Expected behaviour: no user-errors should be generated, when user makes
> > no errors.
>
> Hmm... indeed, but Info-check-pointer catches all errors:
>
>    (defun Info-check-pointer (item)
>      "Non-nil if ITEM is present in this node."
>      (condition-case nil
>          (Info-extract-pointer item)
>        (error nil)))
>
> so that should silence this user-error.
> What am I missing?

Has anybody tried to reproduce this error?  Note that the OP didn't hit
n for that to happen - it happend just while redisplaying.  I don't see
this for emacs -Q.  Could this be related to Emacsspeak?


Regards,

Michael.

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

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Has anybody tried to reproduce this error?  Note that the OP didn't hit
> n for that to happen - it happend just while redisplaying.  I don't see
> this for emacs -Q.  Could this be related to Emacsspeak?

I mean, emacsspeak does things like advising `signal' and `error'.

Michael.

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

[Jarek Czekalski]

W dniu 2013-10-22 07:47, Michael Heerdegen pisze:
> I mean, emacsspeak does things like advising `signal' and `error'.
>

I guess this is the point. Emacspeak doesn't respect the rules of error 
handling. Whether it can do its job in a cleaner way - I don't know yet. 
But I'm convinced that there is no bug in Emacs, because the user-error 
is caught and should not see the surface. I also know how to fix 
Emacspeak in the way it was intended to work.

Please close the ticket. Sorry for bothering you.

As an analogy in other languages we can code:
try {
   c = a / b;
}
catch (DivisionByZero) {
   c = -1;
}
That's fine. If someone wants to intercept all the DivisionByZero 
exceptions, which possibly own dedicated error handlers - they do wrong 
thing.

Thanks
Jarek

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

[Michael Heerdegen]

Jarek Czekalski <jarekczek@poczta.onet.pl> writes:

> Emacspeak doesn't respect the rules of error handling. Whether it can
> do its job in a cleaner way - I don't know yet. But I'm convinced that
> there is no bug in Emacs, because the user-error is caught and should
> not see the surface. I also know how to fix Emacspeak in the way it
> was intended to work.

Since Emacs 22, there is a variable `command-error-function'.  Maybe
Emacspeak could use (bind) it?  Then it hopefully wouldn't have to care
about error handling and catching at all.


Regards,

Michael.

bug#15670: i'll try to get more info

[Jarek Czekalski]

Drew, thanks for the thorough explanation. However I can't see the 
explanation for the question: what kind of error do I experience? It's 
not caused by user, not by code, not by info page. It just needn't have 
always "next" node. So I don't expect any kind of error, even with the 
weirdest definition of error.

Stefan, you seem to agree with me. And the code you quoted agrees as 
well. Thanks for the attention.

I can reproduce, I have the source code and I have you, good people to 
help. I should be able to determine why this does not get caught.

Jarek