bug#48478: 28.0.50; yank-from-kill-ring and kill-ring-yank-pointer

[Juri Linkov <juri@linkov.net>]

>> > In the following use case:
>> >
>> >   M-y
>> >   <type something>
>> >   TAB                     (1)
>> >   <edit the completion>   (2)
>> >   RET
>> >   C-y
>> >
>> > the last C-y inserts neither the unedited completion in (1) nor the
>> > edited one in (2).  It inserts something else.  It should insert one
>> > of these two, IMO, otherwise this behaves very different from
>> >
>> >   C-y
>> >   M-y
>> >   M-y
>> >   ...
>> >   C-y
>> 
>> 'C-y M-y M-y ... C-y' has no ability to edit the previous string,
>> so these cases are not comparable.
>
> You are missing the point.  The point is to tell the user what to
> expect from the next C-y after a series of M-y's.  It makes little
> sense to me to tell them the editing case behaves radically
> differently from the non-editing case.
>
> But if you still disagree, I give up: you win.  The manual will remain
> in its current form, and will not say what happens with the kill-ring
> pointer in this case.

I don't disagree.  I simply don't know what to do.  For example,
above you said to insert one of these two, but which one and how
is completely unclear.  So it seems we need to hear more opinions.