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

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

[Eli Zaretskii]

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?



In GNU Emacs 28.0.50 (build 1311, i686-pc-mingw32)
 of 2021-05-17 built on HOME-C4E4A596F7
Repository revision: e761e12498ff108c3b82e9d27843baec6670447c
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

Configured using:
 'configure -C --prefix=/d/usr --with-wide-int --with-modules
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XPM
ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr dabbrev emacsbug message rmc puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg epg-config gnus-util
rmail rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty
make-network-process emacs)

Memory information:
((conses 16 58121 11610)
 (symbols 48 7814 1)
 (strings 16 21681 2700)
 (string-bytes 1 636473)
 (vectors 16 13335)
 (vector-slots 8 171361 11466)
 (floats 8 27 47)
 (intervals 40 315 68)
 (buffers 888 11))

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> 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?

It feels like a bug to me -- I expect the `C-y' in both situations to
produce the same text as the `M-y' before it.  I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]

> 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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: read-from-kill-ring-prompt.patch --]
[-- Type: text/x-diff, Size: 2348 bytes --]

diff --git a/lisp/isearch.el b/lisp/isearch.el
index 095f8ba145..c52718d94a 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -2583,7 +2585,7 @@ isearch-yank-from-kill-ring
   "Read a string from the `kill-ring' and append it to the search string."
   (interactive)
   (with-isearch-suspended
-   (let ((string (read-from-kill-ring)))
+   (let ((string (read-from-kill-ring "Yank from kill-ring: ")))
      (if (and isearch-case-fold-search
               (eq 'not-yanks search-upper-case))
          (setq string (downcase string)))
diff --git a/lisp/simple.el b/lisp/simple.el
index 90942df0da..08c7c903a8 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -5587,7 +5587,8 @@ yank-pop
 property, in the way that `yank' does."
   (interactive "p")
   (if (not (eq last-command 'yank))
-      (yank-from-kill-ring (read-from-kill-ring) current-prefix-arg)
+      (yank-from-kill-ring (read-from-kill-ring "Yank from kill-ring: ")
+                           current-prefix-arg)
     (setq this-command 'yank)
     (unless arg (setq arg 1))
     (let ((inhibit-read-only t)
@@ -5676,7 +5677,7 @@ rotate-yank-pointer
   (current-kill arg))
 
 (defvar read-from-kill-ring-history)
-(defun read-from-kill-ring ()
+(defun read-from-kill-ring (prompt)
   "Read a `kill-ring' entry using completion and minibuffer history."
   ;; `current-kill' updates `kill-ring' with a possible interprogram-paste
   (current-kill 0)
@@ -5721,11 +5722,7 @@ read-from-kill-ring
              (define-key map "?" nil)
              map)))
       (completing-read
-       ;; FIXME: This prompt is specific to using this function from
-       ;; yank-related commands, but the function could be used in
-       ;; other contexts.  Should the prompt be passed via an
-       ;; argument?
-       "Yank from kill-ring: "
+       prompt
        (lambda (string pred action)
          (if (eq action 'metadata)
              ;; Keep sorted by recency
@@ -5755,7 +5752,8 @@ yank-from-kill-ring
 beginning of the inserted text and mark at the end, like `yank' does.
 
 When called from Lisp, insert STRING like `insert-for-yank' does."
-  (interactive (list (read-from-kill-ring) current-prefix-arg))
+  (interactive (list (read-from-kill-ring "Yank from kill-ring: ")
+                     current-prefix-arg))
   (push-mark)
   (insert-for-yank string)
   (if (consp arg)

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: bug-gnu-emacs@gnu.org
> Date: Tue, 18 May 2021 00:10:57 +0300
> 
> > 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.

Why do we need variants? why not simply do the same as M-y does after
C-y or M-y?  After all, from the user's POV it's the same command, so
why not provide a consistent behavior?

> 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.

The last sentence means that the description in the manual which I
deleted was indeed inaccurate: it described a binding that doesn't
exist by default.  NEWS does a better job by telling users to make
that binding if they want.  (I decided that saying the same in the
manual was too much: we don't describe optional keybindings unless
they are extremely useful/important.)

> A FIXME from 7b82584c69 is implemented by this patch:

Thanks, I think you should install this.

> -(defun read-from-kill-ring ()
> +(defun read-from-kill-ring (prompt)
>    "Read a `kill-ring' entry using completion and minibuffer history."

Please update the doc string to mention PROMPT.

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

[Juri Linkov]

>> 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.
>
> Why do we need variants? why not simply do the same as M-y does after
> C-y or M-y?  After all, from the user's POV it's the same command, so
> why not provide a consistent behavior?

No one objected until now, so there are users who prefer the current behavior.
But I don't disagree with changing the default to use kill-ring-yank-pointer.

>> A FIXME from 7b82584c69 is implemented by this patch:
>
> Thanks, I think you should install this.

Installed.

>> -(defun read-from-kill-ring ()
>> +(defun read-from-kill-ring (prompt)
>>    "Read a `kill-ring' entry using completion and minibuffer history."
>
> Please update the doc string to mention PROMPT.

Done.

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: Tue, 18 May 2021 23:24:24 +0300
> 
> >> 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.
> >
> > Why do we need variants? why not simply do the same as M-y does after
> > C-y or M-y?  After all, from the user's POV it's the same command, so
> > why not provide a consistent behavior?
> 
> No one objected until now, so there are users who prefer the current behavior.

Well, I objected the first time I used this feature after learning
about it.  The reason is that what M-y does after C-y is described in
the manual, so I wanted to see what this new feature does, and was
puzzled by what it did.

> But I don't disagree with changing the default to use kill-ring-yank-pointer.

Let's please do that, TIA.

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

[Juri Linkov]

>> But I don't disagree with changing the default to use kill-ring-yank-pointer.
>
> Let's please do that, TIA.

Now pushed in commit 1f0f922ef2, please close if everything is ok.

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: Wed, 19 May 2021 19:31:06 +0300
> 
> >> But I don't disagree with changing the default to use kill-ring-yank-pointer.
> >
> > Let's please do that, TIA.
> 
> Now pushed in commit 1f0f922ef2, please close if everything is ok.

Thanks, but it doesn't seem to work like I expected.

Here's what I did:

  . emacs -Q
  . Mark several words of the comment in *scratch*, one by one, and
    type M-w to copy each one of them to the kill-ring
  . M-y, then type the beginning of one of the saved words (not the
    last one), type TAB to complete, then type RET to insert
  . C-y

The last didn't C-y insert the word inserted before it by M-y, it
inserted the word in the previous slot of kill-ring.

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

[Juri Linkov]

>> Now pushed in commit 1f0f922ef2, please close if everything is ok.
>
> Thanks, but it doesn't seem to work like I expected.
>
> Here's what I did:
>
>   . emacs -Q
>   . Mark several words of the comment in *scratch*, one by one, and
>     type M-w to copy each one of them to the kill-ring
>   . M-y, then type the beginning of one of the saved words (not the
>     last one), type TAB to complete, then type RET to insert
>   . C-y
>
> The last didn't C-y insert the word inserted before it by M-y, it
> inserted the word in the previous slot of kill-ring.

I didn't expect this case should be handled as well.
Now this is fixed in commit ef7a6eec20.

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: Thu, 20 May 2021 21:02:56 +0300
> 
> > The last didn't C-y insert the word inserted before it by M-y, it
> > inserted the word in the previous slot of kill-ring.
> 
> I didn't expect this case should be handled as well.
> Now this is fixed in commit ef7a6eec20.

Thanks, this use case now works.

However, I'm not sure I understand what happens when I edit the
kill-ring entry before hitting RET, which gets it inserted.  Is the
edited entry added to the kill-ring?  It looks like it isn't, because
the next C-y inserts the last kill-ring entry, i.e. neither the
original entry I edited nor the edited entry actually inserted.  Why
does the kill-ring-yank-pointer gets reset to the front of the
kill-ring in this case?

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

[Juri Linkov]

> However, I'm not sure I understand what happens when I edit the
> kill-ring entry before hitting RET, which gets it inserted.  Is the
> edited entry added to the kill-ring?  It looks like it isn't, because
> the next C-y inserts the last kill-ring entry, i.e. neither the
> original entry I edited nor the edited entry actually inserted.  Why
> does the kill-ring-yank-pointer gets reset to the front of the
> kill-ring in this case?

After inserting the edited entry it resets the kill-ring-yank-pointer
for the same reason why the kill-ring-yank-pointer gets reset
when a new entry gets added to the kill-ring after C-w,
i.e. like this line in 'kill-new':

  (setq kill-ring-yank-pointer kill-ring)

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: Thu, 20 May 2021 22:56:35 +0300
> 
> > However, I'm not sure I understand what happens when I edit the
> > kill-ring entry before hitting RET, which gets it inserted.  Is the
> > edited entry added to the kill-ring?  It looks like it isn't, because
> > the next C-y inserts the last kill-ring entry, i.e. neither the
> > original entry I edited nor the edited entry actually inserted.  Why
> > does the kill-ring-yank-pointer gets reset to the front of the
> > kill-ring in this case?
> 
> After inserting the edited entry it resets the kill-ring-yank-pointer
> for the same reason why the kill-ring-yank-pointer gets reset
> when a new entry gets added to the kill-ring after C-w,
> i.e. like this line in 'kill-new':
> 
>   (setq kill-ring-yank-pointer kill-ring)

I could understand that if the edited entry were added to the
kill-ring.  But it isn't is it?

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

[Juri Linkov]

>> > However, I'm not sure I understand what happens when I edit the
>> > kill-ring entry before hitting RET, which gets it inserted.  Is the
>> > edited entry added to the kill-ring?  It looks like it isn't, because
>> > the next C-y inserts the last kill-ring entry, i.e. neither the
>> > original entry I edited nor the edited entry actually inserted.  Why
>> > does the kill-ring-yank-pointer gets reset to the front of the
>> > kill-ring in this case?
>>
>> After inserting the edited entry it resets the kill-ring-yank-pointer
>> for the same reason why the kill-ring-yank-pointer gets reset
>> when a new entry gets added to the kill-ring after C-w,
>> i.e. like this line in 'kill-new':
>>
>>   (setq kill-ring-yank-pointer kill-ring)
>
> I could understand that if the edited entry were added to the
> kill-ring.  But it isn't is it?

It would be unexpected when yanking the edited entry with M-y
would add it to the kill-ring as its opposite command M-w does.

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: Thu, 20 May 2021 23:44:22 +0300
> 
> >> > However, I'm not sure I understand what happens when I edit the
> >> > kill-ring entry before hitting RET, which gets it inserted.  Is the
> >> > edited entry added to the kill-ring?  It looks like it isn't, because
> >> > the next C-y inserts the last kill-ring entry, i.e. neither the
> >> > original entry I edited nor the edited entry actually inserted.  Why
> >> > does the kill-ring-yank-pointer gets reset to the front of the
> >> > kill-ring in this case?
> >>
> >> After inserting the edited entry it resets the kill-ring-yank-pointer
> >> for the same reason why the kill-ring-yank-pointer gets reset
> >> when a new entry gets added to the kill-ring after C-w,
> >> i.e. like this line in 'kill-new':
> >>
> >>   (setq kill-ring-yank-pointer kill-ring)
> >
> > I could understand that if the edited entry were added to the
> > kill-ring.  But it isn't is it?
> 
> It would be unexpected when yanking the edited entry with M-y
> would add it to the kill-ring as its opposite command M-w does.

Why unexpected?  If we document that, it wouldn't be unexpected.

Once again, we could decide to either add the edited entry to
kill-ring or not add it.  If we don't add it, kill-ring-yank-pointer
should stay at its position, which corresponds to the original entry
before the editing.  If we do add it, the pointer should be reset to
the slot where the edited entry is.  Both of these behaviors can be
easily documented and will be reasonably logical and intuitive,
because they are basically similar to what the old M-y did.  What we
do now is much harder to explain and is not intuitive, at least not
according to my intuition.

Does anyone else have an opinion about this?

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

[Juri Linkov]

>> It would be unexpected when yanking the edited entry with M-y
>> would add it to the kill-ring as its opposite command M-w does.
>
> Why unexpected?  If we document that, it wouldn't be unexpected.
>
> Once again, we could decide to either add the edited entry to
> kill-ring or not add it.  If we don't add it, kill-ring-yank-pointer
> should stay at its position, which corresponds to the original entry
> before the editing.  If we do add it, the pointer should be reset to
> the slot where the edited entry is.  Both of these behaviors can be
> easily documented and will be reasonably logical and intuitive,
> because they are basically similar to what the old M-y did.  What we
> do now is much harder to explain and is not intuitive, at least not
> according to my intuition.

For the case of not adding the edited entry to the kill-ring,
now kill-ring-yank-pointer stays at the same position it was
before the editing.

> Does anyone else have an opinion about this?

Regarding the question whether to add the edited entry to the kill-ring,
let's hear more opinions.

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, 21 May 2021 21:18:33 +0300
> 
> >> It would be unexpected when yanking the edited entry with M-y
> >> would add it to the kill-ring as its opposite command M-w does.
> >
> > Why unexpected?  If we document that, it wouldn't be unexpected.
> >
> > Once again, we could decide to either add the edited entry to
> > kill-ring or not add it.  If we don't add it, kill-ring-yank-pointer
> > should stay at its position, which corresponds to the original entry
> > before the editing.  If we do add it, the pointer should be reset to
> > the slot where the edited entry is.  Both of these behaviors can be
> > easily documented and will be reasonably logical and intuitive,
> > because they are basically similar to what the old M-y did.  What we
> > do now is much harder to explain and is not intuitive, at least not
> > according to my intuition.
> 
> For the case of not adding the edited entry to the kill-ring,
> now kill-ring-yank-pointer stays at the same position it was
> before the editing.

It doesn't look like that in my testing.  Here's the recipe:

  emacs -Q
  For the words "buffer", "text", "Lisp", and "evaluation" from the
    first line, mark each word and then M-w
  M->
  M-y
  Type "tex TAB", which will expand to "text"
  Type "oize RET", which will insert "textoize"
  Type C-y
  This inserts the last kill, which is "evaluation", whereas I
    expected to see "text", since you said the pointer stays at the
    same position.

What am I missing here?

> > Does anyone else have an opinion about this?
> 
> Regarding the question whether to add the edited entry to the kill-ring,
> let's hear more opinions.

OK.

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

[Juri Linkov]

>> For the case of not adding the edited entry to the kill-ring,
>> now kill-ring-yank-pointer stays at the same position it was
>> before the editing.
>
> It doesn't look like that in my testing.  Here's the recipe:
>
>   emacs -Q
>   For the words "buffer", "text", "Lisp", and "evaluation" from the
>     first line, mark each word and then M-w
>   M->
>   M-y
>   Type "tex TAB", which will expand to "text"
>   Type "oize RET", which will insert "textoize"
>   Type C-y
>   This inserts the last kill, which is "evaluation", whereas I
>     expected to see "text", since you said the pointer stays at the
>     same position.

The pointer kill-ring-yank-pointer stays at the same position:
before M-y, kill-ring-yank-pointer points to "evaluation",
and after M-y, kill-ring-yank-pointer points to "evaluation".

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: Sat, 22 May 2021 23:59:31 +0300
> 
> >> For the case of not adding the edited entry to the kill-ring,
> >> now kill-ring-yank-pointer stays at the same position it was
> >> before the editing.
> >
> > It doesn't look like that in my testing.  Here's the recipe:
> >
> >   emacs -Q
> >   For the words "buffer", "text", "Lisp", and "evaluation" from the
> >     first line, mark each word and then M-w
> >   M->
> >   M-y
> >   Type "tex TAB", which will expand to "text"
> >   Type "oize RET", which will insert "textoize"
> >   Type C-y
> >   This inserts the last kill, which is "evaluation", whereas I
> >     expected to see "text", since you said the pointer stays at the
> >     same position.
> 
> The pointer kill-ring-yank-pointer stays at the same position:
> before M-y, kill-ring-yank-pointer points to "evaluation",
> and after M-y, kill-ring-yank-pointer points to "evaluation".

I think this is not the optimal behavior.  The optimal behavior IMO is
if M-y would yield the same results wrt kill-ring-yank-pointer as does
M-y after C-y.  IOW, it would be natural if M-y invoked after a
non-yank command would just allow a "direct access" to a specific slot
of the kill-ring, and would otherwise work like M-y after a yank
command.  Once again, from user's POV M-y is the same command, so
every subtle change in the results is IMO a disadvantage, if the
change is not a direct consequence of the differences in use cases.

If you want yank-from-kill-ring to leave kill-ring-yank-pointer
unaltered, we could move the pointer in yank-pop, after
yank-from-kill-ring returns.  WDYT?

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

[Juri Linkov]

>> The pointer kill-ring-yank-pointer stays at the same position:
>> before M-y, kill-ring-yank-pointer points to "evaluation",
>> and after M-y, kill-ring-yank-pointer points to "evaluation".
>
> I think this is not the optimal behavior.  The optimal behavior IMO is
> if M-y would yield the same results wrt kill-ring-yank-pointer as does
> M-y after C-y.  IOW, it would be natural if M-y invoked after a
> non-yank command would just allow a "direct access" to a specific slot
> of the kill-ring, and would otherwise work like M-y after a yank
> command.  Once again, from user's POV M-y is the same command, so
> every subtle change in the results is IMO a disadvantage, if the
> change is not a direct consequence of the differences in use cases.
>
> If you want yank-from-kill-ring to leave kill-ring-yank-pointer
> unaltered, we could move the pointer in yank-pop, after
> yank-from-kill-ring returns.  WDYT?

When yank-from-kill-ring returns an edited string,
how yank-pop could use it to adjust kill-ring-yank-pointer?

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: Tue, 25 May 2021 23:35:48 +0300
> 
> > If you want yank-from-kill-ring to leave kill-ring-yank-pointer
> > unaltered, we could move the pointer in yank-pop, after
> > yank-from-kill-ring returns.  WDYT?
> 
> When yank-from-kill-ring returns an edited string,

When does it do that?  AFAICT, it _inserts_ the edited string.

> how yank-pop could use it to adjust kill-ring-yank-pointer?

yank-from-kill-ring is a new function, and its return value isn't
documented.  So you could change it to return kill-ring-yank-pointer
instead, and then yank-pop could move it.

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

[Juri Linkov]

>> > If you want yank-from-kill-ring to leave kill-ring-yank-pointer
>> > unaltered, we could move the pointer in yank-pop, after
>> > yank-from-kill-ring returns.  WDYT?
>>
>> When yank-from-kill-ring returns an edited string,
>
> When does it do that?  AFAICT, it _inserts_ the edited string.

Sorry, I meant this:

When read-from-kill-ring returns an edited string,
how yank-from-kill-ring could use it to adjust kill-ring-yank-pointer?

> yank-from-kill-ring is a new function, and its return value isn't
> documented.  So you could change it to return kill-ring-yank-pointer
> instead, and then yank-pop could move it.

I don't understand what value of kill-ring-yank-pointer
should be returned: its old value or some modified value?

BTW, the recent fix in ef7a6eec20 broke such use case:
M-w on some region, but then M-y M-p doesn't insert the last item
to the minibuffer, i.e. the same item that is inserted to the buffer
by C-y.  Here is a workaround:

diff --git a/lisp/simple.el b/lisp/simple.el
index 0d4a712b39..7014f1c24c 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -5735,7 +5736,8 @@ read-from-kill-ring
            (complete-with-action action completions string pred)))
        nil nil nil
        (if history-pos
-           (cons 'read-from-kill-ring-history (1+ history-pos))
+           (cons 'read-from-kill-ring-history
+                 (if (zerop history-pos) history-pos (1+ history-pos)))
          'read-from-kill-ring-history)))))

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: Thu, 27 May 2021 01:09:33 +0300
> 
> When read-from-kill-ring returns an edited string,
> how yank-from-kill-ring could use it to adjust kill-ring-yank-pointer?

read-from-kill-ring could store the pointer in some variable, I guess?

> > yank-from-kill-ring is a new function, and its return value isn't
> > documented.  So you could change it to return kill-ring-yank-pointer
> > instead, and then yank-pop could move it.
> 
> I don't understand what value of kill-ring-yank-pointer
> should be returned: its old value or some modified value?

It depends on whether we add the edited string to the kill ring or
not.  Currently, we don't add it, so I think the value should be that
of the unedited entry in the kill ring.

> BTW, the recent fix in ef7a6eec20 broke such use case:
> M-w on some region, but then M-y M-p doesn't insert the last item
> to the minibuffer, i.e. the same item that is inserted to the buffer

Sorry, I don't understand how does minibiffer enter the picture.  Can
you show a complete recipe?

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

[Juri Linkov]

> After inserting the edited entry it resets the kill-ring-yank-pointer
> for the same reason why the kill-ring-yank-pointer gets reset
> when a new entry gets added to the kill-ring after C-w,
> i.e. like this line in 'kill-new':
>
>   (setq kill-ring-yank-pointer kill-ring)

BTW, bug#21199 asked to remove the above line from 'kill-new',
so C-w could keep the old value of 'kill-ring-yank-pointer'.
Maybe this should be optional?

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

[Juri Linkov]

>> When read-from-kill-ring returns an edited string,
>> how yank-from-kill-ring could use it to adjust kill-ring-yank-pointer?
>
> read-from-kill-ring could store the pointer in some variable, I guess?

There is no way to get the pointer to point to the entry of the kill ring,
because we can't find the edited string in the kill ring.

>> > yank-from-kill-ring is a new function, and its return value isn't
>> > documented.  So you could change it to return kill-ring-yank-pointer
>> > instead, and then yank-pop could move it.
>>
>> I don't understand what value of kill-ring-yank-pointer
>> should be returned: its old value or some modified value?
>
> It depends on whether we add the edited string to the kill ring or
> not.  Currently, we don't add it, so I think the value should be that
> of the unedited entry in the kill ring.

The minibuffer returns only the edited entry that
we can't use to find the unedited entry in the kill ring.

>> BTW, the recent fix in ef7a6eec20 broke such use case:
>> M-w on some region, but then M-y M-p doesn't insert the last item
>> to the minibuffer, i.e. the same item that is inserted to the buffer
>
> Sorry, I don't understand how does minibiffer enter the picture.  Can
> you show a complete recipe?

M-y activates the minibuffer and uses its (HISTVAR . HISTPOS)
to set the initial position for use by the minibuffer history
to the entry pointed by kill-ring-yank-pointer.  So this is similar
to what C-y does when it yanks the same entry pointed by kill-ring-yank-pointer.

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: Mon, 31 May 2021 01:23:54 +0300
> 
> > After inserting the edited entry it resets the kill-ring-yank-pointer
> > for the same reason why the kill-ring-yank-pointer gets reset
> > when a new entry gets added to the kill-ring after C-w,
> > i.e. like this line in 'kill-new':
> >
> >   (setq kill-ring-yank-pointer kill-ring)
> 
> BTW, bug#21199 asked to remove the above line from 'kill-new',
> so C-w could keep the old value of 'kill-ring-yank-pointer'.
> Maybe this should be optional?

Doesn't the new behavior of M-y fill that niche, albeit by other
means?

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: Mon, 31 May 2021 01:32:15 +0300
> 
> >> When read-from-kill-ring returns an edited string,
> >> how yank-from-kill-ring could use it to adjust kill-ring-yank-pointer?
> >
> > read-from-kill-ring could store the pointer in some variable, I guess?
> 
> There is no way to get the pointer to point to the entry of the kill ring,
> because we can't find the edited string in the kill ring.

Then maybe this is another reason to prefer adding the edited string
to the kill-ring?  In which case you will need to reset the pointer to
the head of the ring?

> >> BTW, the recent fix in ef7a6eec20 broke such use case:
> >> M-w on some region, but then M-y M-p doesn't insert the last item
> >> to the minibuffer, i.e. the same item that is inserted to the buffer
> >
> > Sorry, I don't understand how does minibiffer enter the picture.  Can
> > you show a complete recipe?
> 
> M-y activates the minibuffer and uses its (HISTVAR . HISTPOS)
> to set the initial position for use by the minibuffer history
> to the entry pointed by kill-ring-yank-pointer.  So this is similar
> to what C-y does when it yanks the same entry pointed by kill-ring-yank-pointer.

If this is the scenario, then I don't see a problem: what you describe
works for me, i.e. "M-y M-p" does insert the last killed item into the
minibuffer.  I wonder why it doesn't work for you.

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

[Juri Linkov]

>> > After inserting the edited entry it resets the kill-ring-yank-pointer
>> > for the same reason why the kill-ring-yank-pointer gets reset
>> > when a new entry gets added to the kill-ring after C-w,
>> > i.e. like this line in 'kill-new':
>> >
>> >   (setq kill-ring-yank-pointer kill-ring)
>>
>> BTW, bug#21199 asked to remove the above line from 'kill-new',
>> so C-w could keep the old value of 'kill-ring-yank-pointer'.
>> Maybe this should be optional?
>
> Doesn't the new behavior of M-y fill that niche, albeit by other
> means?

The minibuffer version of M-y doesn't reset the pointer anymore indeed.
But users who prefer the non-minibuffer version of M-y still have this problem.

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

[Juri Linkov]

>> >> When read-from-kill-ring returns an edited string,
>> >> how yank-from-kill-ring could use it to adjust kill-ring-yank-pointer?
>> >
>> > read-from-kill-ring could store the pointer in some variable, I guess?
>>
>> There is no way to get the pointer to point to the entry of the kill ring,
>> because we can't find the edited string in the kill ring.
>
> Then maybe this is another reason to prefer adding the edited string
> to the kill-ring?  In which case you will need to reset the pointer to
> the head of the ring?

When there is a need to add the edited string to the kill-ring,
then better to do this explicitly by marking the whole contents of
the edited minibuffer with 'C-x h', then adding it to the kill-ring
with 'M-w'.

>> >> BTW, the recent fix in ef7a6eec20 broke such use case:
>> >> M-w on some region, but then M-y M-p doesn't insert the last item
>> >> to the minibuffer, i.e. the same item that is inserted to the buffer
>> >
>> > Sorry, I don't understand how does minibiffer enter the picture.  Can
>> > you show a complete recipe?
>>
>> M-y activates the minibuffer and uses its (HISTVAR . HISTPOS)
>> to set the initial position for use by the minibuffer history
>> to the entry pointed by kill-ring-yank-pointer.  So this is similar
>> to what C-y does when it yanks the same entry pointed by kill-ring-yank-pointer.
>
> If this is the scenario, then I don't see a problem: what you describe
> works for me, i.e. "M-y M-p" does insert the last killed item into the
> minibuffer.  I wonder why it doesn't work for you.

I tried in 'emacs -Q', and 'M-y M-p' doesn't insert the last killed item
into the minibuffer.

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: Mon, 31 May 2021 23:17:12 +0300
> 
> >> > After inserting the edited entry it resets the kill-ring-yank-pointer
> >> > for the same reason why the kill-ring-yank-pointer gets reset
> >> > when a new entry gets added to the kill-ring after C-w,
> >> > i.e. like this line in 'kill-new':
> >> >
> >> >   (setq kill-ring-yank-pointer kill-ring)
> >>
> >> BTW, bug#21199 asked to remove the above line from 'kill-new',
> >> so C-w could keep the old value of 'kill-ring-yank-pointer'.
> >> Maybe this should be optional?
> >
> > Doesn't the new behavior of M-y fill that niche, albeit by other
> > means?
> 
> The minibuffer version of M-y doesn't reset the pointer anymore indeed.
> But users who prefer the non-minibuffer version of M-y still have this problem.

We introduced what you call "the minibuffer version" for this and
similar use cases, so users who want this feature can invoke that
version of M-y.  So I think we now provide ample solution for that
problem, albeit a different one from the one envisioned there.

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: Mon, 31 May 2021 23:20:04 +0300
> 
> >> >> When read-from-kill-ring returns an edited string,
> >> >> how yank-from-kill-ring could use it to adjust kill-ring-yank-pointer?
> >> >
> >> > read-from-kill-ring could store the pointer in some variable, I guess?
> >>
> >> There is no way to get the pointer to point to the entry of the kill ring,
> >> because we can't find the edited string in the kill ring.
> >
> > Then maybe this is another reason to prefer adding the edited string
> > to the kill-ring?  In which case you will need to reset the pointer to
> > the head of the ring?
> 
> When there is a need to add the edited string to the kill-ring,
> then better to do this explicitly by marking the whole contents of
> the edited minibuffer with 'C-x h', then adding it to the kill-ring
> with 'M-w'.

Sure, but that's unrelated to the issue at hand, isn't it?

> >> >> BTW, the recent fix in ef7a6eec20 broke such use case:
> >> >> M-w on some region, but then M-y M-p doesn't insert the last item
> >> >> to the minibuffer, i.e. the same item that is inserted to the buffer
> >> >
> >> > Sorry, I don't understand how does minibiffer enter the picture.  Can
> >> > you show a complete recipe?
> >>
> >> M-y activates the minibuffer and uses its (HISTVAR . HISTPOS)
> >> to set the initial position for use by the minibuffer history
> >> to the entry pointed by kill-ring-yank-pointer.  So this is similar
> >> to what C-y does when it yanks the same entry pointed by kill-ring-yank-pointer.
> >
> > If this is the scenario, then I don't see a problem: what you describe
> > works for me, i.e. "M-y M-p" does insert the last killed item into the
> > minibuffer.  I wonder why it doesn't work for you.
> 
> I tried in 'emacs -Q', and 'M-y M-p' doesn't insert the last killed item
> into the minibuffer.

It does here, so I guess we are doing something differently.  Can you
show a complete recipe, starting from "emacs -Q"?

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

[Juri Linkov]

>> I tried in 'emacs -Q', and 'M-y M-p' doesn't insert the last killed item
>> into the minibuffer.
>
> It does here, so I guess we are doing something differently.  Can you
> show a complete recipe, starting from "emacs -Q"?

0. emacs -Q
1. select the word "This" and type M-w
2. select the word "buffer" and type M-w
3. type M-y M-p

The minibuffer looks like:

  Yank from kill-ring: This

but should be

  Yank from kill-ring: buffer

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: Tue, 01 Jun 2021 23:32:54 +0300
> 
> >> I tried in 'emacs -Q', and 'M-y M-p' doesn't insert the last killed item
> >> into the minibuffer.
> >
> > It does here, so I guess we are doing something differently.  Can you
> > show a complete recipe, starting from "emacs -Q"?
> 
> 0. emacs -Q
> 1. select the word "This" and type M-w
> 2. select the word "buffer" and type M-w
> 3. type M-y M-p
> 
> The minibuffer looks like:
> 
>   Yank from kill-ring: This
> 
> but should be
> 
>   Yank from kill-ring: buffer

So you don't like that M-p yields "This" and M-n yield "buffer" in
this case?  Why not?  IOW, why did you expect M-p to yield "buffer"?
This is M-y, not C-y.

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

[Juri Linkov]

>> 1. select the word "This" and type M-w
>> 2. select the word "buffer" and type M-w
>> 3. type M-y M-p
>>
>> The minibuffer looks like:
>>
>>   Yank from kill-ring: This
>>
>> but should be
>>
>>   Yank from kill-ring: buffer
>
> So you don't like that M-p yields "This" and M-n yield "buffer" in
> this case?  Why not?  IOW, why did you expect M-p to yield "buffer"?
> This is M-y, not C-y.

But this is not 'M-y C-y'.  The logic is the following:
one key (either non-minibuffer 'C-y' or minibuffer 'M-y') should yank the last item,
two keys (non-minibuffer 'C-y M-y') should yank the second last item.

Another reason is that 'M-y M-p' can omit the last item only
after a previous invocation of 'M-y' that rotated the pointer.

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: Thu, 03 Jun 2021 00:10:18 +0300
> 
> >> 1. select the word "This" and type M-w
> >> 2. select the word "buffer" and type M-w
> >> 3. type M-y M-p
> >>
> >> The minibuffer looks like:
> >>
> >>   Yank from kill-ring: This
> >>
> >> but should be
> >>
> >>   Yank from kill-ring: buffer
> >
> > So you don't like that M-p yields "This" and M-n yield "buffer" in
> > this case?  Why not?  IOW, why did you expect M-p to yield "buffer"?
> > This is M-y, not C-y.
> 
> But this is not 'M-y C-y'.  The logic is the following:
> one key (either non-minibuffer 'C-y' or minibuffer 'M-y') should yank the last item,
> two keys (non-minibuffer 'C-y M-y') should yank the second last item.

That's your logic, not necessarily that of others.  There's no
"M-y M-y" with a preceding C-y, so I don't see any problem in the
current behavior: it can be easily described in the documentation, and
feels natural to me.

But if you want to change it to the behavior you expect, I don't mind.
Just do that (and the setting of the kill-ring pointer) soon, because
currently the documentation of the new behavior of M-y in the manual
is incomplete, and I'd like to complete it before I forget.

Thanks.

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

[Juri Linkov]

> But if you want to change it to the behavior you expect, I don't mind.
> Just do that

It really looked like a bug, so I fixed it now.

> (and the setting of the kill-ring pointer) soon, because
> currently the documentation of the new behavior of M-y in the manual
> is incomplete, and I'd like to complete it before I forget.

Sorry, I forgot what is the setting of the kill-ring pointer?
That needs to be fixed as well?

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: Thu, 03 Jun 2021 23:55:01 +0300
> 
> > (and the setting of the kill-ring pointer) soon, because
> > currently the documentation of the new behavior of M-y in the manual
> > is incomplete, and I'd like to complete it before I forget.
> 
> Sorry, I forgot what is the setting of the kill-ring pointer?
> That needs to be fixed as well?

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

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

[Juri Linkov]

> 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.

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.

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

[Juri Linkov]

>> > 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.

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: Sun, 06 Jun 2021 00:35:58 +0300
> 
> 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.

I think the conclusion up-thread was that if the entry is edited
before it's inserted, then the edited entry should be added to the
head of the kill-ring, and the pointer set there.  IOW, if I edit the
previous kill and insert it, the edited string becomes the one I get
on the next C-y.  The discussion concluded that doing this is possible
without extensive changes, whereas the other alternative is "hard" as
it goes against the current design and implementation of the functions
involved in this.  I'm okay with this behavior, and it is easy to
describe in the manual and easy to remember.

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

[Juri Linkov]

> I think the conclusion up-thread was that if the entry is edited
> before it's inserted, then the edited entry should be added to the
> head of the kill-ring, and the pointer set there.  IOW, if I edit the
> previous kill and insert it, the edited string becomes the one I get
> on the next C-y.  The discussion concluded that doing this is possible
> without extensive changes, whereas the other alternative is "hard" as
> it goes against the current design and implementation of the functions
> involved in this.  I'm okay with this behavior, and it is easy to
> describe in the manual and easy to remember.

I'm still unsure why the command that only yanks text
should add new text to the kill-ring.  This goes against
the logic of yanking because currently only killing commands
can add text to the kill-ring.  So it would be very strange
to call 'kill-new' from 'yank-from-kill-ring':

diff --git a/lisp/simple.el b/lisp/simple.el
index 9e827320f1..1aa720edba 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -5781,8 +5781,9 @@ yank-from-kill-ring
   (insert-for-yank string)
   (when yank-from-kill-ring-rotate
     (let ((pos (seq-position kill-ring string)))
-      (when pos
-        (setq kill-ring-yank-pointer (nthcdr pos kill-ring)))))
+      (if pos
+          (setq kill-ring-yank-pointer (nthcdr pos kill-ring))
+        (kill-new string))))
   (if (consp arg)
       ;; Swap point and mark like in `yank' and `yank-pop'.
       (goto-char (prog1 (mark t)

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: Sun, 06 Jun 2021 23:52:17 +0300
> 
> I'm still unsure why the command that only yanks text
> should add new text to the kill-ring.  This goes against
> the logic of yanking because currently only killing commands
> can add text to the kill-ring.

That's not true: C-y adds to the kill-ring text that it finds in the
clipboard.  So there's nothing new or particularly surprising here,
IMO.

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

[Juri Linkov]

tags 48478 fixed
close 48478 28.0.50
thanks

>> I'm still unsure why the command that only yanks text
>> should add new text to the kill-ring.  This goes against
>> the logic of yanking because currently only killing commands
>> can add text to the kill-ring.
>
> That's not true: C-y adds to the kill-ring text that it finds in the
> clipboard.  So there's nothing new or particularly surprising here,
> IMO.

Sorry, I forgot that C-y adds text to the kill-ring.  So I changed
yank-from-kill-ring to add an edited string to the kill-ring.

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: Tue, 08 Jun 2021 19:55:16 +0300
> 
> Sorry, I forgot that C-y adds text to the kill-ring.  So I changed
> yank-from-kill-ring to add an edited string to the kill-ring.

Thanks, I therefore finalized the documentation of the new behavior of
M-y.

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

[Juri Linkov]

>> Sorry, I forgot that C-y adds text to the kill-ring.  So I changed
>> yank-from-kill-ring to add an edited string to the kill-ring.
>
> Thanks, I therefore finalized the documentation of the new behavior of
> M-y.

I have only one minor remark for this text:

"you can use completion commands to complete on an entry from the list of entries"

It's unclear what "an entry" does mean in case of 'M-y TAB'
that displays the list of all entries.

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, 11 Jun 2021 20:10:01 +0300
> 
> "you can use completion commands to complete on an entry from the list of entries"
> 
> It's unclear what "an entry" does mean in case of 'M-y TAB'
> that displays the list of all entries.

What exactly is unclear here?  "An entry" is on of the "entries" from
the list, what else?

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

[Juri Linkov]

>> "you can use completion commands to complete on an entry from the list of entries"
>>
>> It's unclear what "an entry" does mean in case of 'M-y TAB'
>> that displays the list of all entries.
>
> What exactly is unclear here?  "An entry" is on of the "entries" from
> the list, what else?

I don't know, maybe everything already is correct here.

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

[Eli Zaretskii]

> Date: Fri, 11 Jun 2021 21:06:37 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 48478@debbugs.gnu.org
> 
> What exactly is unclear here?  "An entry" is on of the "entries" from
> the list, what else?                         ^^

Should have been "one", sorry.

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, 11 Jun 2021 21:33:51 +0300
> 
> >> "you can use completion commands to complete on an entry from the list of entries"
> >>
> >> It's unclear what "an entry" does mean in case of 'M-y TAB'
> >> that displays the list of all entries.
> >
> > What exactly is unclear here?  "An entry" is on of the "entries" from
> > the list, what else?
> 
> I don't know, maybe everything already is correct here.

But something did confuse you.  What was that?