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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 48478@debbugs.gnu.org
> Date: Fri, 04 Jun 2021 19:46:00 +0300
> 
> > 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.