GNU bug report logs - #14912
24.3.50; replace.el: Replace error with user-error?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14912 in the body.
You can then email your comments to 14912 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jambunathan K <kjambunathan <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; replace.el: Replace error with user-error?
Date: Fri, 19 Jul 2013 21:58:32 +0530

Very frequently I enable debug-on-error.

This is invariably accompanied with M-x occur RET on some source file
with infinite typings of M-n and M-p s.

Under these conditions, these "spurious" errors get very annoying.  I am
wondering these qualify as `user-error' s.


Debugger entered--Lisp error: (error "No more matches")
  signal(error ("No more matches"))
  error("No more matches")
  (if r (goto-char r) (error message))
  (while (> n 0) (setq r (funcall search (point) (quote occur-match))) (and r (get-text-property r (quote occur-match)) (setq r (funcall search r (quote occur-match)))) (if r (goto-char r) (error message)) (setq n (1- n)))
  (let ((r)) (while (> n 0) (setq r (funcall search (point) (quote occur-match))) (and r (get-text-property r (quote occur-match)) (setq r (funcall search r (quote occur-match)))) (if r (goto-char r) (error message)) (setq n (1- n))))
  occur-find-match(1 previous-single-property-change "No more matches")
  occur-next-error(-1 nil)
  next-error(-1)
  previous-error(1)
  call-interactively(previous-error nil nil)
  command-execute(previous-error)


Debugger entered--Lisp error: (error "No more matches")
  signal(error ("No more matches"))
  error("No more matches")
  (if r (goto-char r) (error message))
  (while (> n 0) (setq r (funcall search (point) (quote occur-match))) (and r (get-text-property r (quote occur-match)) (setq r (funcall search r (quote occur-match)))) (if r (goto-char r) (error message)) (setq n (1- n)))
  (let ((r)) (while (> n 0) (setq r (funcall search (point) (quote occur-match))) (and r (get-text-property r (quote occur-match)) (setq r (funcall search r (quote occur-match)))) (if r (goto-char r) (error message)) (setq n (1- n))))
  occur-find-match(1 next-single-property-change "No more matches")
  occur-next-error(1 nil)
  next-error(nil)
  call-interactively(next-error nil nil)
  command-execute(next-error)



In GNU Emacs 24.3.50.17 (i686-pc-linux-gnu, GTK+ Version 2.20.1)
 of 2013-07-19 on debian-6.05
Bzr revision: 113464 larsi <at> gnus.org-20130719145728-npy1c84plu1mfbns
Windowing system distributor `The X.Org Foundation', version 11.0.10707000
Important settings:
  value of $LANG: en_IN
  locale-coding-system: iso-latin-1-unix
  default enable-multibyte-characters: t

Message #8 received at 14912 <at> debbugs.gnu.org (full text, mbox):

From: Jambunathan K <kjambunathan <at> gmail.com>
To: 14912 <at> debbugs.gnu.org
Subject: Re: bug#14912: 24.3.50; replace.el: Replace error with user-error?
Date: Fri, 19 Jul 2013 22:07:12 +0530

Jambunathan K <kjambunathan <at> gmail.com> writes:

> infinite typings of M-n and M-p s
                      ^^^^^^^^^^^
                    M-g M-n and M-g M-p

Message #11 received at 14912 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Jambunathan K <kjambunathan <at> gmail.com>, 14912 <at> debbugs.gnu.org
Subject: RE: bug#14912: 24.3.50; replace.el: Replace error with user-error?
Date: Fri, 19 Jul 2013 09:51:25 -0700 (PDT)

> Under these conditions, these "spurious" errors get very annoying.  I am
> wondering these qualify as `user-error' s.
> 
> Debugger entered--Lisp error: (error "No more matches")

My vote says yes - user error rather than system error.

But in fact I wonder whether we should even raise an error here,
instead of just showing an informative message.  It is neither a
system error nor a user error that there are no search hits,
a priori.

Yes, no match might in some circumstance indicate an error of
some kind.  But for regular interactive use it does not.  It is
a normal result to be expected from a normal search interaction.
Treating it as an error seems misguided, IMO.

Perhaps such behavior is a (misguided) throwback to a Unix command
such as `grep' which uses an error return value to indicate no
matches.  That is not the context here.

Message #14 received at 14912 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Jambunathan K <kjambunathan <at> gmail.com>
Cc: 14912 <at> debbugs.gnu.org
Subject: Re: bug#14912: 24.3.50; replace.el: Replace error with user-error?
Date: Sat, 20 Jul 2013 04:29:19 -0400

>   signal(error ("No more matches"))
>   error("No more matches")

Should be a user-error,


        Stefan

Message #19 received at 14912-done <at> debbugs.gnu.org (full text, mbox):

From: Jambunathan K <kjambunathan <at> gmail.com>
To: 14912-done <at> debbugs.gnu.org
Subject: Re: bug#14912: 24.3.50; replace.el: Replace error with user-error?
Date: Tue, 01 Jan 2002 06:10:12 +0530

People don't report minor errors?  Why should I?  As OP closing it.

Previous Next

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