summaryrefslogtreecommitdiff
path: root/doc/emacs/killing.texi
diff options
context:
space:
mode:
Diffstat (limited to 'doc/emacs/killing.texi')
-rw-r--r--doc/emacs/killing.texi126
1 files changed, 82 insertions, 44 deletions
diff --git a/doc/emacs/killing.texi b/doc/emacs/killing.texi
index 8434040bcea..6e4fd77e8b9 100644
--- a/doc/emacs/killing.texi
+++ b/doc/emacs/killing.texi
@@ -269,6 +269,21 @@ happens. But if you set the variable @code{kill-read-only-ok} to a
non-@code{nil} value, they just print a message in the echo area to
explain why the text has not been erased.
+@vindex kill-transform-function
+ Before saving the kill to the kill ring, you can transform the
+string using @code{kill-transform-function}. It's called with the
+string to be killed, and it should return the string you want to be
+saved. It can also return @code{nil}, in which case the string won't
+be saved to the kill ring. For instance, if you never want to save
+a pure white space string to the kill ring, you can say:
+
+@lisp
+(setq kill-transform-function
+ (lambda (string)
+ (and (not (string-blank-p string))
+ string)))
+@end lisp
+
@vindex kill-do-not-save-duplicates
If you change the variable @code{kill-do-not-save-duplicates} to a
non-@code{nil} value, identical subsequent kills yield a single
@@ -289,8 +304,9 @@ way to move or copy text is to kill it and then yank it elsewhere.
@item C-y
Yank the last kill into the buffer, at point (@code{yank}).
@item M-y
-Replace the text just yanked with an earlier batch of killed text
-(@code{yank-pop}). @xref{Earlier Kills}.
+Either replace the text just yanked with an earlier batch of killed
+text (@code{yank-pop}), or allow to select from the list of
+previously-killed batches of text. @xref{Earlier Kills}.
@item C-M-w
Cause the following command, if it is a kill command, to append to the
previous kill (@code{append-next-kill}). @xref{Appending Kills}.
@@ -310,13 +326,13 @@ the end. Using any other prefix argument specifies an earlier kill;
e.g., @kbd{C-u 4 C-y} reinserts the fourth most recent kill.
@xref{Earlier Kills}.
- On graphical displays, @kbd{C-y} first checks if another application
-has placed any text in the system clipboard more recently than the
-last Emacs kill. If so, it inserts the clipboard's text instead.
-Thus, Emacs effectively treats ``cut'' or ``copy'' clipboard
-operations performed in other applications like Emacs kills, except
-that they are not recorded in the kill ring. @xref{Cut and Paste},
-for details.
+ On graphical displays and on capable text-mode displays, @kbd{C-y}
+first checks if another application has placed any text in the system
+clipboard more recently than the last Emacs kill. If so, it inserts
+the clipboard's text instead. Thus, Emacs effectively treats ``cut''
+or ``copy'' clipboard operations performed in other applications like
+Emacs kills, except that they are not recorded in the kill ring.
+@xref{Cut and Paste}, for details.
@menu
* Kill Ring:: Where killed text is stored.
@@ -354,7 +370,7 @@ with @kbd{C-h v kill-ring}.
@kbd{C-y} to yank text that is no longer the most recent kill. This
is useful if you remember which kill ring entry you want. If you
don't, you can use the @kbd{M-y} (@code{yank-pop}) command to cycle
-through the possibilities.
+through the possibilities or to select one of the earlier kills.
@kindex M-y
@findex yank-pop
@@ -363,45 +379,64 @@ that was yanked and replaces it with the text from an earlier kill.
So, to recover the text of the next-to-the-last kill, first use
@kbd{C-y} to yank the last kill, and then use @kbd{M-y} to replace it
with the previous kill. This works only after a @kbd{C-y}
-or another @kbd{M-y}.
-
- You can understand @kbd{M-y} in terms of a last-yank pointer which
-points at an entry in the kill ring. Each time you kill, the last-yank
-pointer moves to the newly made entry at the front of the ring.
-@kbd{C-y} yanks the entry which the last-yank pointer points to.
-@kbd{M-y} moves the last-yank pointer to a different entry, and the
-text in the buffer changes to match. Enough @kbd{M-y} commands can move
-the pointer to any entry in the ring, so you can get any entry into the
-buffer. Eventually the pointer reaches the end of the ring; the next
-@kbd{M-y} loops back around to the first entry again.
+or another @kbd{M-y}. (If @kbd{M-y} is invoked after some other
+command, it works differently, see below.)
+
+ You can understand this operation mode of @kbd{M-y} in terms of a
+last-yank pointer which points at an entry in the kill ring. Each
+time you kill, the last-yank pointer moves to the newly made entry at
+the front of the ring. @kbd{C-y} yanks the entry which the last-yank
+pointer points to. @kbd{M-y} after a @kbd{C-y} or another @kbd{M-y}
+moves the last-yank pointer to the previous entry, and the text in the
+buffer changes to match. Enough @kbd{M-y} commands one after another
+can move the pointer to any entry in the ring, so you can get any
+entry into the buffer. Eventually the pointer reaches the end of the
+ring; the next @kbd{M-y} loops back around to the first entry again.
@kbd{M-y} moves the last-yank pointer around the ring, but it does
not change the order of the entries in the ring, which always runs from
the most recent kill at the front to the oldest one still remembered.
- @kbd{M-y} can take a numeric argument, which tells it how many entries
-to advance the last-yank pointer by. A negative argument moves the
-pointer toward the front of the ring; from the front of the ring, it
-moves around to the last entry and continues forward from there.
+ When used after @kbd{C-y} or @kbd{M-y}, @kbd{M-y} can take a numeric
+argument, which tells it how many entries to advance the last-yank
+pointer by. A negative argument moves the pointer toward the front of
+the ring; from the front of the ring, it moves around to the last
+entry and continues forward from there.
- Once the text you are looking for is brought into the buffer, you can
-stop doing @kbd{M-y} commands and it will stay there. It's just a copy
-of the kill ring entry, so editing it in the buffer does not change
-what's in the ring. As long as no new killing is done, the last-yank
-pointer remains at the same place in the kill ring, so repeating
-@kbd{C-y} will yank another copy of the same previous kill.
+ Once the text you are looking for is brought into the buffer, you
+can stop doing @kbd{M-y} commands and the last yanked text will stay
+there. It's just a copy of the kill ring entry, so editing it in the
+buffer does not change what's in the ring. As long as no new killing
+is done, the last-yank pointer remains at the same place in the kill
+ring, so repeating @kbd{C-y} will yank another copy of the same
+previous kill.
When you call @kbd{C-y} with a numeric argument, that also sets the
last-yank pointer to the entry that it yanks.
- Alternatively, when the previous command was not a yank command,
-@kbd{M-y} activates the minibuffer where you can browse previous kills
-using the minibuffer history commands (@pxref{Minibuffer History}), or
-you can use completion commands (@pxref{Completion}) on a list of
-previously killed blocks of text from the kill ring. Exiting the
-minibuffer will insert the selected text to the buffer. With a plain
-prefix argument (@kbd{C-u M-y}), this command leaves the cursor in
-front of the inserted text, and sets the mark at the end.
+ You can also invoke @kbd{M-y} after a command that is not a yank
+command. In that case, @kbd{M-y} prompts you in the minibuffer for
+one of the previous kills. You can use the minibuffer history
+commands (@pxref{Minibuffer History}) to navigate or search through
+the entries in the kill ring until you find the one you want to
+reinsert. Or you can use completion commands (@pxref{Completion
+Commands}) to complete on an entry from the list of entries in the
+kill ring or pop up the @file{*Completions*} buffer with the candidate
+entries from which you can choose. After selecting the kill-ring
+entry, you can optionally edit it in the minibuffer. Finally, type
+@kbd{RET} to exit the minibuffer and insert the text of the selected
+kill-ring entry. Like in case of @kbd{M-y} after another yank
+command, the last-yank pointer is left pointing at the text you just
+yanked, whether it is one of the previous kills or an entry from the
+kill-ring that you edited before inserting it. (In the latter case,
+the edited entry is added to the front of the kill-ring.) So here,
+too, typing @kbd{C-y} will yank another copy of the text just
+inserted.
+
+ When invoked with a plain prefix argument (@kbd{C-u M-y}) after a
+command that is not a yank command, @kbd{M-y} leaves the cursor in
+front of the inserted text, and sets the mark at the end, like
+@kbd{C-y} does.
@node Appending Kills
@subsection Appending Kills
@@ -502,11 +537,14 @@ clipboard.
@vindex save-interprogram-paste-before-kill
When an Emacs kill command puts text in the clipboard, the existing
-clipboard contents are normally lost. Optionally, you can change
-@code{save-interprogram-paste-before-kill} to @code{t}. Then Emacs
-will first save the clipboard to its kill ring, preventing you from
-losing the old clipboard data---at the risk of high memory consumption
-if that data turns out to be large.
+clipboard contents are normally lost. Optionally, Emacs can save the
+existing clipboard contents to the kill ring, preventing you from
+losing the old clipboard data. If
+@code{save-interprogram-paste-before-kill} changed to a number, then
+this data is copied over if it's smaller (in characters) than this
+number. If this variable is any other non-@code{nil} value, it's
+always copied over---at the risk of high memory consumption if that
+data turns out to be large.
Yank commands, such as @kbd{C-y} (@code{yank}), also use the
clipboard. If another application ``owns'' the clipboard---i.e., if