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: Chong Yidong <cyd <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#12819: closed (24.2.50; [PATCH] Fix inconsistent behavior of
 (append-next-kill))
Date: Tue, 17 Dec 2013 15:51:02 +0000

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

Your message dated Tue, 17 Dec 2013 23:50:47 +0800
with message-id <87haa74gtk.fsf <at> gnu.org>
and subject line Re: bug#12819: 24.2.50; [PATCH] Fix inconsistent behavior of (append-next-kill)
has caused the debbugs.gnu.org bug report #12819,
regarding 24.2.50; [PATCH] Fix inconsistent behavior of (append-next-kill)
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> 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: 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 3 (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

[Message part 6 (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.

Previous Next

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