Re: Recentish C-s M-y change

[Juri Linkov]

>> I meant the global C-u M-y.  But since its global meaning makes no sense
>> in isearch, I added C-s C-u M-y as you suggested.
>
> Thank you!
>
> But... could you perhaps also add C-s C-u C-y, as I suggested?  If not, why
> not?  The prefix argument is currently ignored by C-y.

The current interface of isearch-yank-kill and isearch-yank-pop
corresponds exactly to the global commands yank and yank-pop.
So their behaviors are mirrors, but adding C-u to one of them
will break consistency, i.e. C-u of yank and isearch-yank-kill
would have a completely different meaning.

The isearch command currently bound to C-s M-y is a mess for
backward-compatibility, so a prefix argument C-u was necessary to add
to it as a compromise to support the old behavior and the new feature of
M-y.

> I believe accessing the new feature with both C-s C-u C-y and C-s C-u M-y
> is useful: C-s C-u C-y is useful to immediately enter an interactive
> selection (it's convenient because it only uses the control modifier), and
> C-s C-y M-y ... C-u M-y is useful to enter an interactive selection while
> using the non-interactive selection.

BTW, such sequence might not do what you want.  I mean that often after typing
C-s C-y M-y ... C-u M-y, the second C-u M-y doesn't replace the search string
with a string from the kill-ring, it appends it.  I don't know if this is ok
to simply change the implementation to replace the search string instead of
appending, or many users already prefer appending, I have no idea.
Maybe to add a new argument to specify whether append or replace?
Like the argument C-u of the global command yank defines whether
to put point at beginning and mark at end.