From: Dima Kogan <dima@fastmail.fm>
To: 12819@debbugs.gnu.org
Subject: bug#12819: 24.2.50; [PATCH] Fix inconsistent behavior of (append-next-kill)
Date: Tue, 06 Nov 2012 15:33:39 -0800 [thread overview]
Message-ID: <87txt2b92k.fsf@oblong.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1874 bytes --]
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
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Behavior 1 --]
[-- Type: text/x-diff, Size: 1699 bytes --]
From bba4cda29284e84b3266b68c46d0dd4e06afa45f Mon Sep 17 00:00:00 2001
From: Dima Kogan <dima@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
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: Behavior 2 --]
[-- Type: text/x-diff, Size: 827 bytes --]
From 489081f8e53d39aa4f27584882ed5afa8cc53538 Mon Sep 17 00:00:00 2001
From: Dima Kogan <dima@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
next reply other threads:[~2012-11-06 23:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-06 23:33 Dima Kogan [this message]
2013-12-17 15:50 ` bug#12819: 24.2.50; [PATCH] Fix inconsistent behavior of (append-next-kill) Chong Yidong
2013-12-17 16:36 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87txt2b92k.fsf@oblong.com \
--to=dima@fastmail.fm \
--cc=12819@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.