GNU bug report logs -
#12819
24.2.50; [PATCH] Fix inconsistent behavior of (append-next-kill)
Previous Next
Reported by: dima <at> secretsauce.net
Date: Wed, 7 Nov 2012 00:16:02 UTC
Severity: normal
Tags: patch
Found in version 24.2.50
Done: Chong Yidong <cyd <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12819 in the body.
You can then email your comments to 12819 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12819
; Package
emacs
.
(Wed, 07 Nov 2012 00:16:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dima Kogan <dima <at> fastmail.fm>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 07 Nov 2012 00:16:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (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
Changed bug submitter to 'dima <at> secretsauce.net' from 'Dima Kogan <dima <at> fastmail.fm>'
Request was from
Dima Kogan <dima <at> secretsauce.net>
to
control <at> debbugs.gnu.org
.
(Thu, 21 Feb 2013 05:31:02 GMT)
Full text and
rfc822 format available.
Reply sent
to
Chong Yidong <cyd <at> gnu.org>
:
You have taken responsibility.
(Tue, 17 Dec 2013 15:51:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
dima <at> secretsauce.net
:
bug acknowledged by developer.
(Tue, 17 Dec 2013 15:51:03 GMT)
Full text and
rfc822 format available.
Message #12 received at 12819-done <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12819
; Package
emacs
.
(Tue, 17 Dec 2013 16:37:02 GMT)
Full text and
rfc822 format available.
Message #15 received at 12819-done <at> debbugs.gnu.org (full text, mbox):
> > 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.
It is, however, quite a (good) change from longstanding previous
behavior. This should be mentioned in NEWS.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 15 Jan 2014 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 10 years and 113 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.