James Thomas writes:

> Eli Zaretskii writes:
>
>>> From: James Thomas
>>> Cc: stefankangas@gmail.com,  77857@debbugs.gnu.org
>>> Date: Sun, 20 Apr 2025 12:29:39 +0530
>>> 
>>> Eli Zaretskii writes:
>>> 
>>> >> From: James Thomas
>>> >> Cc: Eli Zaretskii,  77857@debbugs.gnu.org
>>> >> Date: Sat, 19 Apr 2025 14:54:27 +0530
>>> >> 
>>> >> Stefan Kangas writes:
>>> >> 
>>> >> > Makes sense to me, but I think we should make it optional somehow.  It's
>>> >> > not the typical use case, and it changes current behavior.
>>> >> 
>>> >> Eli Zaretskii writes:
>>> >> 
>>> >> > That's an incompatible change in behavior, no?
>>> >> 
>>> >> Well... no (isn't it?). It only happens with 'C-M-w' before 'w', which
>>> >> currently has no effect: (info "(emacs) Appending Kills").
>>> >
>>> > That's the change: previously Emacs produced different results in this
>>> > case.  People might not expect the 'w' command to do that, they might
>>> > expect that their previous kill remains intact.
>>> 
>>> No, I mean, they'd _have_ to press 'C-M-w' for that to happen, right
>>> before the 'w' - which they'd do only if they wanted this.
>>> 
>>> I think we're miscommunicating:
>>> 
>>>   Previously: C-M-w w: A simple copy (so no one would type the C-M-w).
>>>   Now:        C-M-w w: Appended to the previous kill.
>>> 
>>> (There's no change in 'w's behaviour without an immediately preceding
>>> 'C-M-w')
>>
>> What I have in mind is the sequence "M-w w" or "C-w w".  AFAIU,
>> previously, 'w' would start a new kill-ring entry, but with your
>> suggestion it will append to whatever C-w/M-w killed before it.
>> Right?
>
> The first wouldn't, because 'M-w' is not 'kill-region', and for the
> second, one would have to _move out_ of the form field (where the 'C-w'
> happened) before pressing 'w'.
>
> But indeed, when I came up with this I hadn't thought of the situation
> where 'w' is rebound to a key-chord, perhaps, so that it could be typed
> immediately after, in the latter case above. So the question now is
> whether it's even desirable in such a (IMO, rare) case. If so, here's an
> updated patch with a News entry.

Updated with doc fixes: