Re: isearch-query-replace-regexp and stuff

[David Kastrup]

Juri Linkov <address@hidden> writes:

> David Kastrup <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.
> 
> That might seem weird, but it allows users to do weird things if they
> want so.  Users may want to search with C-s for a regexp in the
> buffer and start C-M-% with a regexp copied literally from the search
> string.

This is not what I guessed from the code, but I might be mistaken.
But I don't consider it likely.  And the same reasoning would hold
that users might want to search with C-u C-s for a regexp and start
C-M-% with regexp copied literally from the search string.  If you
want to start over with something you found, then start over.  It does
not make sense to define some secret switch-horses functionality here.
The other thing that might make sense is to just define M-% and use it
to start regexp replacements in regexp searches, and non-regexp
replaced in normal isearch.  It might be confusing.  OTOH, the C-s
binding during searches already has this sort of split personality.

> > 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 have no brilliant idea of what to do if we type M-% in a regexp
> > isearch and there is no currently matched string.  Probably just beep
> > and refuse, which would also be the sanest option if the regexp is
> > currently incomplete.  Of course, if query-replace-interactive is
> > 'initial, one might possibly just provide an empty string as initial
> > value (leaving the history in peace), and if it is nil, we need not
> > bother anyhow.
> 
> All this makes sense.  We could implement this for the sake of user
> convenience provided that this is what most users would expect, but
> often mandatory conveniences are too annoying.

Well, the existing behavior does not seem particularly useful, and
far from obvious.  My proposal has the purpose of keeping a
successful search successful.

> > While we are at it: maybe M-s should turn an ordinary search into
> > a regexp search (while regexp-quoting the current search string to
> > make it fitting for a regexp search), and vice versa (by using the
> > currently matched string, if any, as search string).
> 
> Do you propose a new key binding M-s or do you actually mean
> modifying the existing M-r?  M-r currently toggles regular-expression
> mode, but it neither quotes the regexp nor turns the search regexp
> into the matched string.

Oops, didn't realize that.

> We could use a prefix argument of M-r to implement these things
> instead of adding a new key binding.

No, we couldn't.  Prefix arguments exit the search.  It might make
sense when switching to use the respective search history's last entry
_if_ it happens to match at point.  That way, M-r M-r would be a noop
instead of turning a general regexp into one just matching a string.
OTOH, there is little motivation for typing M-r M-r anyhow.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum