> If one uses "C-y M-y M-y ... C-y", the last C-y will yank the > same kill-ring entry that the M-y before it. But if one uses > "M-y M-y ... C-y", the last C-y will yank not the entry produced > by the last M-y, but the one after it. Which means > yank-from-kill-ring leaves the kill-ring-yank-pointer at a different > entry than yank-pop does. > > Bug or feature? If the latter, what is the rationale for the > different operation? This is an unfinished feature, i.e. currently yank-from-kill-ring simply has no special handling of kill-ring-yank-pointer. When I tried to add it, I noticed that it has many possible variants of implementation, so I stuck with analysis paralysis. Perhaps we should have a new option with several choices: 1. Don't change kill-ring-yank-pointer (as it does now). This is useful when the user wants to type a predictable number of M-p in the minibuffer history to yank the same previously-killed text from the kill-ring several times. 2. Adjust kill-ring-yank-pointer to point to the selected text. 3. Still unclear how to adjust kill-ring-yank-pointer when the user selects a previous text then edits it before yanking. Regarding 7b82584c69, actually the description of 'M-y' in (info "(emacs) Isearch Yank") was accurate. It correctly described the behavior of isearch-yank-pop that activates the minibuffer. The problem is that after recent controversy, 'M-y' was rebound to the backward-compatible command isearch-yank-pop-only. A FIXME from 7b82584c69 is implemented by this patch: