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

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

[Jambunathan K]

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

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

[Jambunathan K]

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

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

[Jambunathan K]

Jambunathan K <kjambunathan@gmail.com> writes:

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

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

[Drew Adams]

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

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

[Stefan Monnier]

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

Should be a user-error,


        Stefan