Re: query-replace-interactive

[Juri Linkov <juri@jurta.org>]

Stefan <monnier@iro.umontreal.ca> writes:
>> But the last search string still could be used as the `default'
>> argument of `read-from-minibuffer'.  This is not quite a "default"
>> value but rather what the Emacs manual names as "future history" value,
>> i.e. the value available with M-n.
>
> I think we've already agreed that M-% should offer
>
>    Query replace (default foo -> bar): 
>
> i.e. default to redo the same replace as last time, rather than use the
> last search string.

Even if using the last replacement as default doesn't hurt, such use
of the default value is non-standard in Emacs.  Usually, the default
value is available for inserting into the minibuffer by typing M-n,
but not in this case, since inserting "foo -> bar" into the minibuffer
is useless.  Moreover, the last replacement actually consists of the
last elements of the replacement history.  The standard Emacs way to
access the history values is M-p.  But this is not possible for two
separate replacement values (from and to) either.

One possibility to follow Emacs conventions is to use a user-defined
value `query-replace-args-separator' to allow to specify both
from-string and to-string in the same input string.  In this case
there is no need in interpreting an empty input string as repeating
the last replacement since the last replacement (as well as all
previous replacements) are easily accessible by M-p.  However, I am
not sure this option should have some non-nil value by default.

But even in case with the default to repeat the last replacement it is
possible to use the last search string/regexp as a default value only
for the sake of making it available by M-n.  But the real default value
(such as used when the user types RET with empty input) could be
interpreted as repeating the last replacement, since if the user
enters empty input, `read-from-minibuffer' returns the empty string,
not the argument `default-value'.

>> I implemented it having in mind users' requests for the ability to
>> copy words from the buffer into the from-string.  Now this is possible
>> by typing:
>
>> C-s C-w C-w ... M-%
>
> C-SPC M-f M-f ... M-w M-% C-y

Yes, currently this is the most convenient method to do that but it
requires more keystrokes and wastes the kill ring.

There are other cases where making the last search string accessible
by M-n is useful.  For example, users might want to start replacing
the current search string from the beginning of the buffer.  To not
type C-r several times to reach the beginning of the buffer the user
can type:

C-s C-w C-w ... RET M-< M-% M-n RET

So, in conclusion, I agree that M-% in isearch should not ask for
the from-string with initial content of the last search string,
but M-% invoked not from isearch could provide the last search string
by M-n.

>>> (perform-replace isearch-string nil t isearch-regexp isearch-word) instead.
>>                                   ===
>> If the argument `replacements' is nil, this function signals an error.
>> Moreover, it's impossible to guess the to-string, so asking for it from
>> the user is still inevitable.
>
> Oh, right, I forgot that part of my local hacks
> [...]
> Obviously, it's not good enough.  But we can easily take out the "read
> `to'" part of query-replace-read-args.

Calling `perform-replace' directly is not good because it skips many
useful things implemented in interactive commands which call it.
Most useful of them is recently added handling of \, and \# in
`query-replace-read-args'.

> The point about using perform-replace is that it allows us to obey
> both isearch-regexp and isearch-word without doing any if-gymnastic.

Using `isearch-regexp' to call either `query-replace' or
`query-replace-regexp' is easy.  Using the value of `isearch-word' for
replacement might be tricky but currently this is possible with the
prefix argument C-u M-% or C-u C-M-% even in isearch.

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