GNU bug report logs -
#79197
[PATCH] ; * lisp/simple.el (yank): Update docstring.
Previous Next
To reply to this bug, email your comments to 79197 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79197; Package
emacs.
(Thu, 07 Aug 2025 21:23:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
James Thomas <jimjoe <at> gmx.net>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 07 Aug 2025 21:23:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[0001-lisp-simple-el--yank---Update-docstring.patch (text/x-patch, attachment)]
[Message part 2 (text/plain, inline)]
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79197; Package
emacs.
(Fri, 08 Aug 2025 06:07:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 79197 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 08 Aug 2025 02:52:28 +0530
> From: James Thomas via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> +If N is negative, reinsert the earliest available kill.
Thanks, but that is not what I see when I try "C-u - 1 C-y". It
inserts the 2nd earliest kill, i.e., not the first one I killed, but
the one after it. Which seems to be consistent with this snippet:
(insert-for-yank (current-kill (cond
((listp arg) 0)
((eq arg '-) -2)
(t (1- arg)))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79197; Package
emacs.
(Fri, 08 Aug 2025 22:39:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 79197 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii writes:
>> Date: Fri, 08 Aug 2025 02:52:28 +0530
>> From: James Thomas via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> +If N is negative, reinsert the earliest available kill.
>
> Thanks, but that is not what I see when I try "C-u - 1 C-y". It
> inserts the 2nd earliest kill, i.e., not the first one I killed, but
> the one after it. Which seems to be consistent with this snippet:
Well, obviously, because it's wrong! :-) And undocumented to boot...
[0001-Fix-yank-behavior-with-negative-prefix-arg-bug-79197.patch (text/x-patch, attachment)]
[Message part 3 (text/plain, inline)]
(All caveats associated with ancient code are implicit)
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79197; Package
emacs.
(Sat, 09 Aug 2025 06:17:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 79197 <at> debbugs.gnu.org (full text, mbox):
> From: James Thomas <jimjoe <at> gmx.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>
> Date: Sat, 09 Aug 2025 04:08:06 +0530
>
> Eli Zaretskii writes:
>
> >> Date: Fri, 08 Aug 2025 02:52:28 +0530
> >> From: James Thomas via "Bug reports for GNU Emacs,
> >> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >>
> >> +If N is negative, reinsert the earliest available kill.
> >
> > Thanks, but that is not what I see when I try "C-u - 1 C-y". It
> > inserts the 2nd earliest kill, i.e., not the first one I killed, but
> > the one after it. Which seems to be consistent with this snippet:
>
> Well, obviously, because it's wrong! :-) And undocumented to boot...
Your patch is the exact opposite of commit 8e5d85ffc0, and will make
"C-u -" produce a different effect from "C-u - 1", which is very
surprising. So at least we need to also change the handling of
negative numerical argument as well, to make them consistent.
And anyway, something is still amiss. Try killing several pieces of
text, then type "C-u - 1 C-y" several times, with some typing between
the yank commands (to avoid any dwim-ish behavior when several yank
commands are invoked one after another). That is,
C-u - 1 C-y
foo
C-u - 1 C-y
foo
C-u - 1 C-y
foo
C-u - 1 C-y
foo
C-u - 1 C-y
foo
Each yank will insert a different text, so saying "the earliest kill
available" is incorrect, because what that "earliest" kill is depends
on what the user manual calls "last yank pointer". See current-kill,
which determines what happens here. (The manual doesn't say anything
about negative arguments to C-y, which is at least interesting.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79197; Package
emacs.
(Sat, 09 Aug 2025 07:50:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 79197 <at> debbugs.gnu.org (full text, mbox):
> Cc: 79197 <at> debbugs.gnu.org
> Date: Sat, 09 Aug 2025 09:15:50 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> Your patch is the exact opposite of commit 8e5d85ffc0, and will make
> "C-u -" produce a different effect from "C-u - 1", which is very
> surprising. So at least we need to also change the handling of
> negative numerical argument as well, to make them consistent.
Oh, and when you look into this, please also consider what should be
the meaning of a zero argument.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79197; Package
emacs.
(Sat, 09 Aug 2025 22:04:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 79197 <at> debbugs.gnu.org (full text, mbox):
I guess one could make it do what (I think) it was supposed to do by putting an inverse nthcdr of the kill-ring and its cdr position, in "-2"'s place.
I suspect that someone fell into the same thinking trap in testing that I (and perhaps you) did.
Zero simply moves by one newer kill, as of now.
I should've written "With a negative prefix argument" instead of that, anyway.
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79197; Package
emacs.
(Sat, 09 Aug 2025 22:58:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 79197 <at> debbugs.gnu.org (full text, mbox):
> I guess one could make it do what (I think) it was supposed to do by putting an inverse nthcdr of the kill-ring and its cdr position, in "-2"'s place.
And account for the ring's length being the maximum possible, and its changes. All this if the position were available, i.e.
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79197; Package
emacs.
(Sun, 10 Aug 2025 00:46:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 79197 <at> debbugs.gnu.org (full text, mbox):
So, to sum up, AFAIU:
The first time the ring position is shifted for it's own sake (by the user, using a numeric prefix), the relative positions may not be considered, equivalently, as absolute time-ordinal ones.
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79197; Package
emacs.
(Sun, 10 Aug 2025 02:51:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 79197 <at> debbugs.gnu.org (full text, mbox):
If I'm right, it seems to a mystery about a commit committed in the past, finally solved! :D (it was a dark and stormy night here).
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79197; Package
emacs.
(Sun, 10 Aug 2025 05:26:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 79197 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 10 Aug 2025 08:20:22 +0530
> From: James Thomas <jimjoe <at> gmx.net>
> CC: monnier <at> iro.umontreal.ca, Eli Zaretskii <eliz <at> gnu.org>
>
> If I'm right, it seems to a mystery about a commit committed in the past, finally solved! :D (it was a dark and stormy night here).
Sorry, I'm confused by the several messages you posted, without any
clear reference to what I wrote. Would you mind replying to my
message with specific answers to the questions I asked and the issues
I raised?
TIA
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79197; Package
emacs.
(Mon, 11 Aug 2025 05:33:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 79197 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Fri, 08 Aug 2025 02:52:28 +0530
>> From: James Thomas via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> +If N is negative, reinsert the earliest available kill.
>
> Thanks, but that is not what I see when I try "C-u - 1 C-y". It
> inserts the 2nd earliest kill, i.e., not the first one I killed, but
> the one after it. Which seems to be consistent with this snippet:
>
> (insert-for-yank (current-kill (cond
> ((listp arg) 0)
> ((eq arg '-) -2)
> (t (1- arg)))))
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Cc: 79197 <at> debbugs.gnu.org
>> Date: Sat, 09 Aug 2025 09:15:50 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>>
>> Your patch is the exact opposite of commit 8e5d85ffc0, and will make
>> "C-u -" produce a different effect from "C-u - 1", which is very
>> surprising. So at least we need to also change the handling of
>> negative numerical argument as well, to make them consistent.
Here's my story:
In the kill-'ring', the position is only relative, not an absolute one
of the order in which kills were entered. The 'negative prefix' argument
yielding what it does seems to have been an attempt to get the 'earliest
kill available': which is ultimately doomed, because no such state is
stored specifically. Normally, -2 would give you that. But if the
kill-ring pointer is ever moved backward (by C-y, M-y ... or C-u <n>
C-y) the assumption breaks down.
>
> Oh, and when you look into this, please also consider what should be
> the meaning of a zero argument.
C-u 0 simply gives the 'next' kill. For instance, I often use: C-y, M-y
... until I find the first one in a series of kills, then follow up with
C-u 0 C-y, ... to recreate the whole.
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Sun, 10 Aug 2025 08:20:22 +0530
>> From: James Thomas <>
>> CC: monnier <at> iro.umontreal.ca, Eli Zaretskii <eliz <at> gnu.org>
>>
>> If I'm right, it seems to a mystery about a commit committed in the
>> past, finally solved! :D (it was a dark and stormy night here).
>
> Sorry, I'm confused by the several messages you posted, without any
> clear reference to what I wrote. Would you mind replying to my
> message with specific answers to the questions I asked and the issues
> I raised?
>
> TIA
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79197; Package
emacs.
(Mon, 11 Aug 2025 12:30:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 79197 <at> debbugs.gnu.org (full text, mbox):
OTOH, does this fix everything?
diff --git a/lisp/simple.el b/lisp/simple.el
index cd13e0a55f4..97701ead69d 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -5758,9 +5758,10 @@ kill-new
(setcar kill-ring string)
(let ((history-delete-duplicates nil))
(add-to-history 'kill-ring string kill-ring-max t))))
- (setq kill-ring-yank-pointer kill-ring)
+ (prog1
+ (setq kill-ring-yank-pointer kill-ring)
(if interprogram-cut-function
- (funcall interprogram-cut-function string))))
+ (funcall interprogram-cut-function string)))))
;; It has been argued that this should work like `self-insert-command'
;; which merges insertions in `buffer-undo-list' in groups of 20
@@ -6399,7 +6400,8 @@ yank
(push-mark)
(insert-for-yank (current-kill (cond
((listp arg) 0)
- ((eq arg '-) -1)
+ ((eq arg '-) (- (length kill-ring)
+ (length kill-ring-yank-pointer)))
(t (1- arg)))))
(if (consp arg)
;; This is like exchange-point-and-mark, but doesn't activate the mark.
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79197; Package
emacs.
(Mon, 11 Aug 2025 12:34:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 79197 <at> debbugs.gnu.org (full text, mbox):
> From: James Thomas <jimjoe <at> gmx.net>
> Cc: 79197 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> Date: Mon, 11 Aug 2025 11:01:35 +0530
>
> > (insert-for-yank (current-kill (cond
> > ((listp arg) 0)
> > ((eq arg '-) -2)
> > (t (1- arg)))))
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Cc: 79197 <at> debbugs.gnu.org
> >> Date: Sat, 09 Aug 2025 09:15:50 +0300
> >> From: Eli Zaretskii <eliz <at> gnu.org>
> >>
> >> Your patch is the exact opposite of commit 8e5d85ffc0, and will make
> >> "C-u -" produce a different effect from "C-u - 1", which is very
> >> surprising. So at least we need to also change the handling of
> >> negative numerical argument as well, to make them consistent.
>
> Here's my story:
>
> In the kill-'ring', the position is only relative, not an absolute one
> of the order in which kills were entered. The 'negative prefix' argument
> yielding what it does seems to have been an attempt to get the 'earliest
> kill available': which is ultimately doomed, because no such state is
> stored specifically. Normally, -2 would give you that. But if the
> kill-ring pointer is ever moved backward (by C-y, M-y ... or C-u <n>
> C-y) the assumption breaks down.
>
> >
> > Oh, and when you look into this, please also consider what should be
> > the meaning of a zero argument.
>
> C-u 0 simply gives the 'next' kill. For instance, I often use: C-y, M-y
> ... until I find the first one in a series of kills, then follow up with
> C-u 0 C-y, ... to recreate the whole.
OK, so given these observations, how do you propose to continue? Do
you have a patch to propose, either for the doc string or for the code
or both? if so, please show the patch, and let's take it from there.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79197; Package
emacs.
(Mon, 11 Aug 2025 13:09:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 79197 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: James Thomas <>
>> Cc: 79197 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
>> Date: Mon, 11 Aug 2025 11:01:35 +0530
>>
>> > (insert-for-yank (current-kill (cond
>> > ((listp arg) 0)
>> > ((eq arg '-) -2)
>> > (t (1- arg)))))
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> Cc: 79197 <at> debbugs.gnu.org
>> >> Date: Sat, 09 Aug 2025 09:15:50 +0300
>> >> From: Eli Zaretskii <eliz <at> gnu.org>
>> >>
>> >> Your patch is the exact opposite of commit 8e5d85ffc0, and will make
>> >> "C-u -" produce a different effect from "C-u - 1", which is very
>> >> surprising. So at least we need to also change the handling of
>> >> negative numerical argument as well, to make them consistent.
>>
>> Here's my story:
>>
>> In the kill-'ring', the position is only relative, not an absolute one
>> of the order in which kills were entered. The 'negative prefix' argument
>> yielding what it does seems to have been an attempt to get the 'earliest
>> kill available': which is ultimately doomed, because no such state is
>> stored specifically. Normally, -2 would give you that. But if the
>> kill-ring pointer is ever moved backward (by C-y, M-y ... or C-u <n>
>> C-y) the assumption breaks down.
>>
>> >
>> > Oh, and when you look into this, please also consider what should be
>> > the meaning of a zero argument.
>>
>> C-u 0 simply gives the 'next' kill. For instance, I often use: C-y, M-y
>> ... until I find the first one in a series of kills, then follow up with
>> C-u 0 C-y, ... to recreate the whole.
>
> OK, so given these observations, how do you propose to continue? Do
> you have a patch to propose, either for the doc string or for the code
> or both? if so, please show the patch, and let's take it from there.
diff --git a/lisp/simple.el b/lisp/simple.el
index cd13e0a55f4..97701ead69d 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -5758,9 +5758,10 @@ kill-new
(setcar kill-ring string)
(let ((history-delete-duplicates nil))
(add-to-history 'kill-ring string kill-ring-max t))))
- (setq kill-ring-yank-pointer kill-ring)
+ (prog1
+ (setq kill-ring-yank-pointer kill-ring)
(if interprogram-cut-function
- (funcall interprogram-cut-function string))))
+ (funcall interprogram-cut-function string)))))
;; It has been argued that this should work like `self-insert-command'
;; which merges insertions in `buffer-undo-list' in groups of 20
@@ -6399,7 +6400,8 @@ yank
(push-mark)
(insert-for-yank (current-kill (cond
((listp arg) 0)
- ((eq arg '-) -1)
+ ((eq arg '-) (- (length kill-ring)
+ (length kill-ring-yank-pointer)))
(t (1- arg)))))
(if (consp arg)
;; This is like exchange-point-and-mark, but doesn't activate the mark.
(Because the earlier one might've been malformed)
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79197; Package
emacs.
(Mon, 11 Aug 2025 13:50:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 79197 <at> debbugs.gnu.org (full text, mbox):
> From: James Thomas <jimjoe <at> gmx.net>
> Cc: 79197 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> Date: Mon, 11 Aug 2025 18:37:38 +0530
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > OK, so given these observations, how do you propose to continue? Do
> > you have a patch to propose, either for the doc string or for the code
> > or both? if so, please show the patch, and let's take it from there.
>
>
> diff --git a/lisp/simple.el b/lisp/simple.el
> index cd13e0a55f4..97701ead69d 100644
> --- a/lisp/simple.el
> +++ b/lisp/simple.el
> @@ -5758,9 +5758,10 @@ kill-new
> (setcar kill-ring string)
> (let ((history-delete-duplicates nil))
> (add-to-history 'kill-ring string kill-ring-max t))))
> - (setq kill-ring-yank-pointer kill-ring)
> + (prog1
> + (setq kill-ring-yank-pointer kill-ring)
> (if interprogram-cut-function
> - (funcall interprogram-cut-function string))))
> + (funcall interprogram-cut-function string)))))
Why do we need this hunk?
> ;; It has been argued that this should work like `self-insert-command'
> ;; which merges insertions in `buffer-undo-list' in groups of 20
> @@ -6399,7 +6400,8 @@ yank
> (push-mark)
> (insert-for-yank (current-kill (cond
> ((listp arg) 0)
> - ((eq arg '-) -1)
> + ((eq arg '-) (- (length kill-ring)
> + (length kill-ring-yank-pointer)))
> (t (1- arg)))))
So, once again "C-u -" and "C-u - 1" will produce different results?
And what about documenting the effect of a negative arg?
Thanks.
P.S. The change in behavior for negative arguments might need to be
called out in NEWS, in case someone had that in their muscle memory
for some reason.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79197; Package
emacs.
(Mon, 11 Aug 2025 14:06:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 79197 <at> debbugs.gnu.org (full text, mbox):
The last one, I promise (whether right or wrong):
diff --git a/lisp/simple.el b/lisp/simple.el
index cd13e0a55f4..415aea6874c 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -5758,9 +5758,10 @@ kill-new
(setcar kill-ring string)
(let ((history-delete-duplicates nil))
(add-to-history 'kill-ring string kill-ring-max t))))
- (setq kill-ring-yank-pointer kill-ring)
+ (prog1
+ (setq kill-ring-yank-pointer kill-ring)
(if interprogram-cut-function
- (funcall interprogram-cut-function string))))
+ (funcall interprogram-cut-function string)))))
;; It has been argued that this should work like `self-insert-command'
;; which merges insertions in `buffer-undo-list' in groups of 20
@@ -6399,7 +6400,7 @@ yank
(push-mark)
(insert-for-yank (current-kill (cond
((listp arg) 0)
- ((eq arg '-) -1)
+ ((eq arg '-) (1- (length kill-ring-yank-pointer)))
(t (1- arg)))))
(if (consp arg)
;; This is like exchange-point-and-mark, but doesn't activate the mark.
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79197; Package
emacs.
(Tue, 12 Aug 2025 21:46:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 79197 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: James Thomas <>
>> Cc: 79197 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
>> Date: Mon, 11 Aug 2025 18:37:38 +0530
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > OK, so given these observations, how do you propose to continue? Do
>> > you have a patch to propose, either for the doc string or for the code
>> > or both? if so, please show the patch, and let's take it from there.
>>
>>
>> diff --git a/lisp/simple.el b/lisp/simple.el
>> index cd13e0a55f4..97701ead69d 100644
>> --- a/lisp/simple.el
>> +++ b/lisp/simple.el
>> @@ -5758,9 +5758,10 @@ kill-new
>> (setcar kill-ring string)
>> (let ((history-delete-duplicates nil))
>> (add-to-history 'kill-ring string kill-ring-max t))))
>> - (setq kill-ring-yank-pointer kill-ring)
>> + (prog1
>> + (setq kill-ring-yank-pointer kill-ring)
>> (if interprogram-cut-function
>> - (funcall interprogram-cut-function string))))
>> + (funcall interprogram-cut-function string)))))
>
> Why do we need this hunk?
For the correct return value?
>
>> ;; It has been argued that this should work like `self-insert-command'
>> ;; which merges insertions in `buffer-undo-list' in groups of 20
>> @@ -6399,7 +6400,8 @@ yank
>> (push-mark)
>> (insert-for-yank (current-kill (cond
>> ((listp arg) 0)
>> - ((eq arg '-) -1)
>> + ((eq arg '-) (- (length kill-ring)
>> + (length kill-ring-yank-pointer)))
>> (t (1- arg)))))
>
> So, once again "C-u -" and "C-u - 1" will produce different results?
>
> And what about documenting the effect of a negative arg?
>
> Thanks.
It was final only for yesterday. :D
A docstring update that turned out to be a bugfix for a faeture that
wasn't:
[0001-Bugfix-79197-yank-does-not-insert-earliest-kill-cons.patch (text/x-patch, attachment)]
[Message part 3 (text/plain, inline)]
Also, my personal wishlist has a new entry: A similar -ve prefix for
yank-pop equivalent to -1: would be useful after this...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79197; Package
emacs.
(Thu, 14 Aug 2025 20:26:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 79197 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
James Thomas <> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: James Thomas <>
>>> Cc: 79197 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
>>> Date: Mon, 11 Aug 2025 18:37:38 +0530
>>>
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>
>>> > OK, so given these observations, how do you propose to continue? Do
>>> > you have a patch to propose, either for the doc string or for the code
>>> > or both? if so, please show the patch, and let's take it from there.
>>>
>>>
>>> diff --git a/lisp/simple.el b/lisp/simple.el
>>> index cd13e0a55f4..97701ead69d 100644
>>> --- a/lisp/simple.el
>>> +++ b/lisp/simple.el
>>> @@ -5758,9 +5758,10 @@ kill-new
>>> (setcar kill-ring string)
>>> (let ((history-delete-duplicates nil))
>>> (add-to-history 'kill-ring string kill-ring-max t))))
>>> - (setq kill-ring-yank-pointer kill-ring)
>>> + (prog1
>>> + (setq kill-ring-yank-pointer kill-ring)
>>> (if interprogram-cut-function
>>> - (funcall interprogram-cut-function string))))
>>> + (funcall interprogram-cut-function string)))))
>>
>> Why do we need this hunk?
>
> For the correct return value?
Mea culpa:
[0001-Bugfix-79197-yank-does-not-insert-earliest-kill-cons.patch (text/x-patch, attachment)]
[Message part 3 (text/plain, inline)]
>
>>
>>> ;; It has been argued that this should work like `self-insert-command'
>>> ;; which merges insertions in `buffer-undo-list' in groups of 20
>>> @@ -6399,7 +6400,8 @@ yank
>>> (push-mark)
>>> (insert-for-yank (current-kill (cond
>>> ((listp arg) 0)
>>> - ((eq arg '-) -1)
>>> + ((eq arg '-) (- (length kill-ring)
>>> + (length kill-ring-yank-pointer)))
>>> (t (1- arg)))))
>>
>> So, once again "C-u -" and "C-u - 1" will produce different results?
>>
>> And what about documenting the effect of a negative arg?
>>
>> Thanks.
>
> It was final only for yesterday. :D
>
> A docstring update that turned out to be a bugfix for a faeture that
> wasn't:
>
>
>
>
> Also, my personal wishlist has a new entry: A similar -ve prefix for
> yank-pop equivalent to -1: would be useful after this...
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79197; Package
emacs.
(Fri, 15 Aug 2025 06:02:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 79197 <at> debbugs.gnu.org (full text, mbox):
> From: James Thomas <jimjoe <at> gmx.net>
> Cc: 79197 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> Date: Fri, 15 Aug 2025 01:55:28 +0530
>
> --- a/lisp/simple.el
> +++ b/lisp/simple.el
> @@ -6354,6 +6354,9 @@ yank
> at beginning, and mark at end.
> With argument N, reinsert the Nth most recent kill.
>
> +With the negative prefix argument, reinsert the earliest kill
> +available.
Should we explain more explicitly what is "the earliest kill
available"? In any case, this sentence is only correct for "C-u -",
but not, say, for "C-u - 3", right?
Maybe we should simply say that negative arguments count from the
earliest kill backwards? And explain that with an example in the
manual?
> @@ -6397,7 +6400,7 @@ yank
> (push-mark)
> (insert-for-yank (current-kill (cond
> ((listp arg) 0)
> - ((eq arg '-) -2)
> + ((eq arg '-) (1- (length kill-ring-yank-pointer)))
> (t (1- arg)))))
I'd prefer to have here code that explicitly handles negative number
arguments in the same way it handles "C-u -". Otherwise,
understanding this code is harder. It also makes the code a tad
harder to maintain, because (1- (length kill-ring-yank-pointer)) is
implicitly dependent on what current-kill does with negative arguments.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79197; Package
emacs.
(Fri, 15 Aug 2025 07:40:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 79197 <at> debbugs.gnu.org (full text, mbox):
>>> diff --git a/lisp/simple.el b/lisp/simple.el
>>> index cd13e0a55f4..97701ead69d 100644
>>> --- a/lisp/simple.el
>>> +++ b/lisp/simple.el
>>> @@ -5758,9 +5758,10 @@ kill-new
>>> (setcar kill-ring string)
>>> (let ((history-delete-duplicates nil))
>>> (add-to-history 'kill-ring string kill-ring-max t))))
>>> - (setq kill-ring-yank-pointer kill-ring)
>>> + (prog1
>>> + (setq kill-ring-yank-pointer kill-ring)
>>> (if interprogram-cut-function
>>> - (funcall interprogram-cut-function string))))
>>> + (funcall interprogram-cut-function string)))))
>>
>> Why do we need this hunk?
>
> For the correct return value?
That's already what `prog1` says in the code, so it just pushes the
question a step further: why do we care about the return value here?
The docstring doesn't mention anything about the return value (so it's
not clear which value is more "correct"), and a quick perusal of the
code suggests that most callers don't care about the return value.
So, if we keep this hunk, it should come with a comment explaining why
we care, or a change to the docstring to document the return value.
Stefan
This bug report was last modified 3 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.