Invalid search bound (wrong side of point)

Invalid search bound (wrong side of point)

[Juri Linkov]

`perform-replace' signals an error even during normal operation such
as replacing a string in the active region with transient mark mode
enabled.  This bug can be reproduced by evaluating in the *scratch* buffer:

(progn
  (transient-mark-mode 1)
  (insert "\na\n\n\n")
  (perform-replace "^" " " nil t nil nil nil (- (point) 4) (- (point) 2)))

`perform-replace' uses nil value returned from `re-search-forward'
as a condition to terminate the loop, but when the value of point
becomes greater than limit, "Invalid search bound" error is signalled,
even though `noerror' argument of `re-search-forward' is t.

Generally, this error can be observed by evaluating in this buffer by C-x C-e:

(re-search-forward "abc" (point-min) t)

whereas evaluating the following expression simply returns nil:

(re-search-forward "def" (point-max) t)

It seems that `search_command' should be changed to not signal an
"Invalid search bound" error if its `noerror' argument is non-nil.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Invalid search bound (wrong side of point)

[Andreas Schwab]

Juri Linkov <juri@jurta.org> writes:

> It seems that `search_command' should be changed to not signal an
> "Invalid search bound" error if its `noerror' argument is non-nil.

I don't think so.  This error is unrelated to the meaning of the `noerror'
argument.  The latter only suppresses the search-failed error, all other
errors are still signalled.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Invalid search bound (wrong side of point)

[Richard Stallman]

    `perform-replace' uses nil value returned from `re-search-forward'
    as a condition to terminate the loop, but when the value of point
    becomes greater than limit, "Invalid search bound" error is signalled,
    even though `noerror' argument of `re-search-forward' is t.

I think that is correct behavior.  Invalid arguments are a different
matter from valid arguments but no match.

The clean solution is for perform-replace to detect the situation
explicitly.