From: Drew Adams <drew.adams@oracle.com>
To: Noam Postavsky <npostavs@gmail.com>, Markus Triska <triska@metalevel.at>
Cc: 40375@debbugs.gnu.org, schwab@linux-m68k.org
Subject: bug#40375: 27.0.50; yank unexpectedly depends on progn
Date: Mon, 13 Apr 2020 15:44:53 -0700 (PDT) [thread overview]
Message-ID: <eb54695c-f58c-4546-98d6-fc2b0775e21c@default> (raw)
In-Reply-To: <8736973ubp.fsf@gmail.com>
> Does this look okay? (modulo a fill-paragraph which I've held off on
> just to make the patch easier to read)
>
> --- i/lisp/simple.el
> +++ w/lisp/simple.el
> @@ -5110,7 +5110,9 @@ yank-pop
> (defun yank (&optional arg)
> "Reinsert (\"paste\") the last stretch of killed text.
> More precisely, reinsert the most recent kill, which is the
> -stretch of killed text most recently killed OR yanked. Put point
> +stretch of text most recently killed or yanked. Or text from the
> +system clipboard if that was modified more recently (see
> +`interprogram-paste-function'). Put point
> at the end, and set mark at the beginning without activating it.
> With just \\[universal-argument] as argument, put point at beginning,
> and mark at end.
> With argument N, reinsert the Nth most recent kill.
Sorry for butting in here; just happened to see this in passing.
Till now, it was OK to talk only about killing or yanking, as the source of the text to be yanked ("the most recent kill").
But there's also copying text to the kill ring, as if it were killed. And putting text on the kill ring is analogous to putting it onto the system clipboard. In both cases you can get it to that saved-text place by killing/cutting OR by copying.
So to be parallel in the doc maybe we should say "text from the kill-ring or from the system clipboard if..."
Users should have a good sense that the same kind of thing is involved: text gets put on some save location (kill ring or clipboard), and then it gets yanked from there. With your text above, it seems like only killing and yanking is used for the kill ring, but killing or copying is used for the clipboard.
(If what I'm saying isn't clear to you, ignore it. It's not a big deal.)
next prev parent reply other threads:[~2020-04-13 22:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-01 16:14 bug#40375: 27.0.50; yank unexpectedly depends on progn Markus Triska
2020-04-01 16:57 ` Noam Postavsky
2020-04-01 17:53 ` Markus Triska
2020-04-01 23:11 ` Noam Postavsky
2020-04-13 16:14 ` Noam Postavsky
2020-04-13 16:22 ` Markus Triska
2020-04-13 16:30 ` Noam Postavsky
2020-04-13 16:35 ` Andreas Schwab
2020-04-13 18:01 ` Markus Triska
2020-04-13 18:34 ` Eli Zaretskii
2020-04-13 18:52 ` Markus Triska
2020-04-13 19:35 ` Eli Zaretskii
2020-04-13 19:46 ` Markus Triska
2020-04-13 22:16 ` Noam Postavsky
2020-04-13 22:44 ` Drew Adams [this message]
2020-04-14 5:39 ` Eli Zaretskii
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=eb54695c-f58c-4546-98d6-fc2b0775e21c@default \
--to=drew.adams@oracle.com \
--cc=40375@debbugs.gnu.org \
--cc=npostavs@gmail.com \
--cc=schwab@linux-m68k.org \
--cc=triska@metalevel.at \
/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.