GNU bug report logs -
#79197
[PATCH] ; * lisp/simple.el (yank): Update docstring.
Previous Next
Full log
View this message in rfc822 format
> 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.
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.