Re: isearch-query-replace-regexp and stuff

[David Kastrup]

Richard Stallman <address@hidden> writes:

>     As far as I am able to judge from the current code that is just
>     checked in, if one types M-% from within a regexp isearch or C-M-%
>     from within an ordinary isearch, the history variable of the last
>     irrelevant search type gets consulted.
> 
>     That seems weird.  I think that M-% from within a regexp isearch
>     should probably use the currently matched string, and C-M-% from
>     within an ordinary isearch should probably use regexp-quote of the
>     current search string.
> 
> I think M-% in string search should do query-replace
> and M-% in regexp search should do query-replace-regexp.
> That is simple, easy to type, and involves fewer characters.

Agreed.  The change-type-of-search functionality is something weird
enough that one does not want to spend to much time thinking about
how to throw this at the user.

It might be an idea to also bind C-M-% to the same, non-type-switching
behavior for symmetry.  If the user wants to switch behavior, he can
do so with the existing M-r binding.  To make this more useful than
just exiting search and restarting replacement, we might consider
letting M-r in isearches keep the search string if it non-empty.
This might be done in one of several ways:

a) keep the search string unmodified.  This has the advantage that
you can keep already typed search string characters even when you
accidentally started with the wrong search type.

b) start over.  I think this might be the current behavior.  It does
not buy you anything over leaving the current isearch and starting
over with a different one.

c) regexp-quote the search string when going to regexp searches, do
something useful when going backward.  That was my original
proposal.  It has the advantage that an existing match remains an
existing match.

After thinking this over, I think that maybe something like option
"a)" would more often agree with what the user could expect and which
would offer the most _additional_ usefulness.  The main question to
resolve for that would be just _where_ to start looking for the next
match under the changed conditions.  Probably resuming the search from
the last position that _did_ match anything?  That might make sense if
you repeat searching a few times, add something like [ and then notice
(because of a non-match) that you really wanted a regexp search
instead.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum