From: Howard Melman <hmelman@gmail.com>
To: 46621@debbugs.gnu.org
Subject: bug#46621: Copy line
Date: Sun, 21 Feb 2021 18:04:00 -0500 [thread overview]
Message-ID: <lyblcddnvj.fsf@Lumet2.home> (raw)
In-Reply-To: <87tuq99ova.fsf@mail.linkov.net>
Juri Linkov <juri@linkov.net> writes:
>> Once in a while I want to do that. It is easy: C-a C-k C-k,
>> they C-y as many times as needed.
I do this occasionally. Usually it's in something like
markdown-mode. Typically I'm creating lists and want to
write out a bunch of formatting characters before going back
and filling in text. So I might want 10-12 lines like:
- [ ]
which is a markdown list item with a checkbox, before going
back and filing in text without having to type odd
punctuation characters. Sometimes I might put a date string
in there too or some other prefix string.
It's emacs I can do this many different ways. I might do
the C-a C-k C-k C-y C-y ... dance. Typically I'll make 4
lines then kill those 4 lines and yank them 3 times. I
might just type my text and then go back and use
string-rectangle to insert the markup. If it were more
involved I might use a macro.
If there were a duplicate-line command that took an arg to
duplicate it arg times I'd probably start using that. I
probably wouldn't bother to write it myself (I haven't in
30+ years).
>> Instead of a command to duplicate the current line repeatedly,
>> how about a command to yank the current kill repeatedly?
>> That would be useful in a much broader range of situations.
>>
>> I wonder if the current meaning of the numeric argument to C-y (reach
>> back in the kill ring) is actually useful. Would it be better for
>> it to repeat the yank in this way?
>
> It's not realistic to change the meaning of the numeric arg to C-y.
> People already use the current meaning for decades.
Actually, I'd like that and this is a place where I think
completion systems influence that decision.
I don't use an arg to C-y. If I want something from the
kill-ring that isn't the last thing, I'll C-y and then M-y
until I get it. I'm not remembering I want the 3rd to last
thing I killed and if I'm off by one I think it's a pain to
fix. I might do that if I were writing a complex keyboard
macro and concentrating for it but I'd probably use
registers instead.
But in particular with modern completion systems I'd
definitely like this change to yank's arg. While I do C-y
M-y for simple stuff, if I want something I've yanked from
longer ago, instead I'll use something like consult-yank or
counsel-yank. These use the kill-region as completion
candidates and show the candidates, one per line, in the
minibuffer with all the completion tools available (most
have options to cope with multi-line text). I bind it to
M-y globally so if I want to yank something old I skip C-y
entirely and just type M-y and then might use completion and
narrowing if I don't see it near the top of the list. As a
result, the current arg to C-y is useless to me because
completion offers a much better experience.
--
Howard
next prev parent reply other threads:[~2021-02-21 23:04 UTC|newest]
Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-18 19:07 bug#46621: Copy line Juri Linkov
2021-02-18 19:30 ` bug#46621: [External] : " Drew Adams
2021-02-20 6:58 ` Richard Stallman
2021-02-19 13:09 ` Lars Ingebrigtsen
2021-02-19 20:27 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-20 6:54 ` Eli Zaretskii
2021-02-20 13:05 ` Lars Ingebrigtsen
2021-02-20 13:12 ` Eli Zaretskii
2021-02-20 13:18 ` Lars Ingebrigtsen
2021-02-20 14:15 ` Eli Zaretskii
2021-02-20 14:35 ` Dmitry Gutov
2021-02-20 13:03 ` Lars Ingebrigtsen
2021-02-20 18:28 ` Juri Linkov
2021-02-21 6:16 ` Richard Stallman
2021-02-21 6:21 ` Richard Stallman
2021-02-21 8:54 ` Juri Linkov
2021-02-21 10:41 ` Eli Zaretskii
2021-02-21 13:12 ` Lars Ingebrigtsen
2021-02-21 13:19 ` Eli Zaretskii
2021-02-21 15:51 ` Lars Ingebrigtsen
2021-02-21 17:06 ` Eli Zaretskii
2021-02-21 17:39 ` Lars Ingebrigtsen
2021-02-21 18:00 ` bug#46621: [External] : " Drew Adams
2021-02-21 17:45 ` Drew Adams
2021-02-22 6:22 ` Richard Stallman
2021-02-21 17:41 ` bug#46621: [External] : " Drew Adams
2021-02-21 20:37 ` Juri Linkov
2021-02-21 22:06 ` bug#46621: [External] : " Drew Adams
2021-02-22 15:45 ` Eli Zaretskii
2021-02-21 23:04 ` Howard Melman [this message]
2021-02-22 6:23 ` Richard Stallman
2021-02-22 9:07 ` Juri Linkov
2021-02-22 15:43 ` Eli Zaretskii
2021-02-22 16:28 ` Helmut Eller
2021-02-22 16:58 ` Andreas Schwab
2021-02-22 18:32 ` Helmut Eller
2021-02-22 19:41 ` Howard Melman
2021-02-22 19:46 ` bug#46621: [External] : " Drew Adams
2021-02-23 19:29 ` Dmitry Gutov
2022-06-28 14:28 ` Drew Adams
2021-02-22 17:08 ` Eli Zaretskii
2021-02-22 18:42 ` Helmut Eller
2021-02-22 17:04 ` Gregory Heytings
2021-02-22 17:16 ` Eli Zaretskii
2021-02-22 17:54 ` Gregory Heytings
2021-02-22 20:51 ` Stephen Berman
2021-02-21 13:13 ` Lars Ingebrigtsen
2022-06-17 17:34 ` Lars Ingebrigtsen
2022-06-18 9:32 ` Simen Heggestøyl
2022-06-20 18:28 ` Richard Stallman
2022-06-18 18:02 ` Mattias Engdegård
2022-06-18 18:09 ` Eli Zaretskii
2022-06-19 15:02 ` Mattias Engdegård
2022-07-03 17:21 ` Mattias Engdegård
2022-07-04 3:24 ` Pankaj Jangid
2022-07-05 16:02 ` Mattias Engdegård
2022-07-05 16:52 ` Lars Ingebrigtsen
2022-07-05 20:19 ` Mattias Engdegård
2022-06-19 11:43 ` Lars Ingebrigtsen
2022-06-19 15:20 ` Mattias Engdegård
2022-06-19 15:22 ` Lars Ingebrigtsen
2022-06-20 9:26 ` Mattias Engdegård
2022-06-21 10:35 ` Lars Ingebrigtsen
2022-06-21 11:13 ` Mattias Engdegård
2022-06-22 4:11 ` Lars Ingebrigtsen
2022-06-21 17:41 ` Juri Linkov
2022-06-22 4:07 ` Lars Ingebrigtsen
2022-06-22 7:28 ` Juri Linkov
2022-06-22 7:54 ` Lars Ingebrigtsen
2022-06-22 17:21 ` Pankaj Jangid
2022-06-22 18:24 ` Juri Linkov
2022-06-22 18:45 ` Lars Ingebrigtsen
2022-06-23 7:49 ` Lars Ingebrigtsen
2022-06-23 8:08 ` Pankaj Jangid
2022-06-23 8:17 ` Andreas Schwab
2022-06-23 9:05 ` Lars Ingebrigtsen
2022-07-06 17:34 ` Juri Linkov
2022-07-07 7:58 ` Lars Ingebrigtsen
2022-07-07 16:45 ` Juri Linkov
2022-07-07 18:03 ` Lars Ingebrigtsen
2022-07-07 18:20 ` Juri Linkov
2022-07-07 18:24 ` Lars Ingebrigtsen
2022-07-08 17:10 ` Juri Linkov
2022-07-10 12:57 ` Lars Ingebrigtsen
2022-07-14 17:16 ` Juri Linkov
2022-07-14 17:47 ` Andreas Schwab
2022-07-14 19:30 ` Juri Linkov
2022-06-23 9:22 ` Robert Pluim
2022-06-23 11:16 ` Pankaj Jangid
2022-06-23 11:34 ` Lars Ingebrigtsen
2022-06-23 9:04 ` Lars Ingebrigtsen
2022-06-23 11:12 ` Pankaj Jangid
2022-06-23 15:10 ` Mattias Engdegård
2022-06-23 15:20 ` Lars Ingebrigtsen
2022-06-25 16:35 ` Mattias Engdegård
2022-06-23 17:35 ` Juri Linkov
2022-06-23 17:49 ` Drew Adams
2022-06-25 16:51 ` Mattias Engdegård
2022-06-25 17:48 ` Drew Adams
2022-06-27 19:40 ` Juri Linkov
2022-06-28 8:41 ` Mattias Engdegård
2022-06-28 12:10 ` Helmut Eller
2022-06-22 14:10 ` Drew Adams
2022-06-22 17:27 ` Pankaj Jangid
2022-06-22 20:44 ` Sean Whitton
2022-06-22 20:50 ` Drew Adams
2022-06-23 15:47 ` Helmut Eller
2022-06-23 16:07 ` Eli Zaretskii
2022-06-23 17:46 ` Drew Adams
2022-06-23 5:47 ` Eli Zaretskii
2022-06-23 17:00 ` Sean Whitton
2022-06-23 17:37 ` Sean Whitton
2022-06-23 18:31 ` Eli Zaretskii
2022-06-30 16:31 ` Sean Whitton
2022-07-01 9:27 ` Lars Ingebrigtsen
2022-07-01 16:34 ` Sean Whitton
[not found] <87a6aal3l5.fsf@simenheg@gmail.com>
2022-06-18 12:56 ` Lars Ingebrigtsen
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=lyblcddnvj.fsf@Lumet2.home \
--to=hmelman@gmail.com \
--cc=46621@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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).