GNU bug report logs - #12819
24.2.50; [PATCH] Fix inconsistent behavior of (append-next-kill)

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: dima <at> secretsauce.net
Subject: bug#12819: closed (Re: bug#12819: 24.2.50; [PATCH] Fix
 inconsistent behavior of (append-next-kill))
Date: Tue, 17 Dec 2013 15:51:03 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#12819: 24.2.50; [PATCH] Fix inconsistent behavior of (append-next-kill)

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 12819 <at> debbugs.gnu.org.

-- 
12819: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12819
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Chong Yidong <cyd <at> gnu.org>
To: Dima Kogan <dima <at> fastmail.fm>
Cc: 12819-done <at> debbugs.gnu.org
Subject: Re: bug#12819: 24.2.50;
 [PATCH] Fix inconsistent behavior of (append-next-kill)
Date: Tue, 17 Dec 2013 23:50:47 +0800

Dima Kogan <dima <at> fastmail.fm> writes:

> I'm attaching a patch that implements behavior 1 and another that
> implements behavior 2. I have a mild preference for behavior 1, but both
> are better than what emacs does currently, I think.

Thanks.  Patch 1 looks OK, and a bit of testing did not turn up any
problems, so I've committed it to trunk.

[Message part 3 (message/rfc822, inline)]

From: Dima Kogan <dima <at> fastmail.fm>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.2.50; [PATCH] Fix inconsistent behavior of (append-next-kill)
Date: Tue, 06 Nov 2012 15:33:39 -0800

[Message part 4 (text/plain, inline)]

The behavior of appended kills is described in

http://www.gnu.org/software/emacs/manual/html_node/emacs/Appending-Kills.html

The idea is that when consecutive kills happen, the new text is either
appended or prepended to the kill ring entry, depending on the ordering
of the mark/point. This works as described for commands such as C-k,
M-d, etc. However, the behavior for C-w and M-w is surprising.

Suppose my buffer contains

123

with the point at the '1'. I then use point navigation commands, C-M-w
and C-w to kill 1 then 2 then 3:

C-SPC C-f C-w C-SPC C-f C-M-w C-w C-SPC C-f C-M-w C-w

I would expect the kill-ring to then contain "123". Instead, it contains
"321". Similarly I get "321" if I do this backwards, i.e. starting with
the point at the '3':

C-SPC C-f C-w C-SPC C-b C-M-w C-w C-SPC C-b C-M-w C-w C-y


If I perform similar actions, but with M-w instead of C-w, I get "123"
for the forward case and "321" for the backward case. I would expect
"123" in all cases.


The current behavior for commands after C-M-w is:

C-w: prepend if point>mark; append otherwise
M-w: always append new kill


I think the behavior should either

1. Match what commands like M-d do; "123" would then result in all 4 of
   the cases described above

or

2. Always append. This is what the manual node at the top of this report
   says. The 4 cases described above would then produce "123", "321",
   "123", "321" respectively.


I'm attaching a patch that implements behavior 1 and another that
implements behavior 2. I have a mild preference for behavior 1, but both
are better than what emacs does currently, I think.

Historically, the behavior has been "always-append". The current
behavior was established in 2006 by
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=b7690594

I think the intent of that commit was to implement behavior 1, but I'm
not sure.

dima

[0001-C-w-M-w-after-C-M-w-now-pre-ap-pend-intelligently-to.patch (text/x-diff, inline)]

From bba4cda29284e84b3266b68c46d0dd4e06afa45f Mon Sep 17 00:00:00 2001
From: Dima Kogan <dima <at> oblong.com>
Date: Tue, 6 Nov 2012 15:17:38 -0800
Subject: [PATCH] C-w/M-w after C-M-w now pre/ap-pend intelligently to
 preserve input ordering

---
 lisp/simple.el |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lisp/simple.el b/lisp/simple.el
index aed945d..67577e0 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -3358,7 +3358,7 @@ the text killed this time appends to the text killed last time
 to make one entry in the kill ring."
   ;; Pass point first, then mark, because the order matters
   ;; when calling kill-append.
-  (interactive (list (point) (mark)))
+  (interactive (list (mark) (point)))
   (unless (and beg end)
     (error "The mark is not set now, so there is no region"))
   (condition-case nil
@@ -3399,7 +3399,7 @@ If `interprogram-cut-function' is non-nil, also save the text for a window
 system cut and paste.
 
 This command's old key binding has been given to `kill-ring-save'."
-  (interactive "r")
+  (interactive (list (mark) (point)))
   (if (eq last-command 'kill-region)
       (kill-append (filter-buffer-substring beg end) (< end beg))
     (kill-new (filter-buffer-substring beg end)))
@@ -3417,7 +3417,7 @@ use \\[append-next-kill] before \\[kill-ring-save].
 
 This command is similar to `copy-region-as-kill', except that it gives
 visual feedback indicating the extent of the region being copied."
-  (interactive "r")
+  (interactive (list (mark) (point)))
   (copy-region-as-kill beg end)
   ;; This use of called-interactively-p is correct because the code it
   ;; controls just gives the user visual feedback.
-- 
1.7.10.4

[0001-C-w-M-w-after-C-M-w-now-always-append-to-the-prior-k.patch (text/x-diff, inline)]

From 489081f8e53d39aa4f27584882ed5afa8cc53538 Mon Sep 17 00:00:00 2001
From: Dima Kogan <dima <at> oblong.com>
Date: Tue, 6 Nov 2012 15:27:20 -0800
Subject: [PATCH] C-w/M-w after C-M-w now always append to the prior kill-ring
 element

---
 lisp/simple.el |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/simple.el b/lisp/simple.el
index aed945d..94a9991 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -3358,7 +3358,7 @@ the text killed this time appends to the text killed last time
 to make one entry in the kill ring."
   ;; Pass point first, then mark, because the order matters
   ;; when calling kill-append.
-  (interactive (list (point) (mark)))
+  (interactive "r")
   (unless (and beg end)
     (error "The mark is not set now, so there is no region"))
   (condition-case nil
-- 
1.7.10.4

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.