GNU bug report logs -
#46621
Copy line
Previous Next
Reported by: Juri Linkov <juri <at> linkov.net>
Date: Thu, 18 Feb 2021 19:14:01 UTC
Severity: wishlist
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.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 46621 in the body.
You can then email your comments to 46621 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#46621; Package
emacs.
(Thu, 18 Feb 2021 19:14:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Juri Linkov <juri <at> linkov.net>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 18 Feb 2021 19:14:01 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)]
Why there is still no such fundamental command as duplicating the current
line? This command slightly extends the existing copy-from-above-command:
[copy-line.patch (text/x-diff, inline)]
diff --git a/lisp/misc.el b/lisp/misc.el
index 09f6011f98..b3b7d8355f 100644
--- a/lisp/misc.el
+++ b/lisp/misc.el
@@ -61,6 +61,16 @@ copy-from-above-command
(+ n (point)))))))
(insert string)))
+;;;###autoload
+(defun copy-line (&optional arg)
+ "Duplicate the current line ARG times."
+ (interactive "p")
+ (dotimes (_ arg)
+ (forward-line 1)
+ (insert "\n")
+ (forward-line -1)
+ (copy-from-above-command)))
+
;; Variation of `zap-to-char'.
;;;###autoload
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 18 Feb 2021 19:31:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> Why there is still no such fundamental command as duplicating the
> current line? This command slightly extends the existing
> copy-from-above-command:
"still"?
"fundamental command"?
In the 35+ years of Emacs, has anyone actually
requested/missed this?
We seem to be adding this & that simple command
more & more - perhaps just because it's available
in other editors?
(Next, we'll dedicate a default key for this...)
The right approach for this kind of thing, IMO, is
for users to create and use such a command. Then
after a while they start asking for it by default,
and we maybe add it, if it's a real lack.
I've nothing against such a command. But I've
also never felt the need for it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Fri, 19 Feb 2021 13:10:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> Why there is still no such fundamental command as duplicating the current
> line? This command slightly extends the existing copy-from-above-command:
Hm... So this would basically just allow you to get X number of the
line?
Well, I don't object to adding it, but I'm not sure what the use case is
here? The only time I can remember wanting something like that is when
I'm filling a buffer with text for test purposes, which is perhaps not a
compelling use case.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Fri, 19 Feb 2021 20:28:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
> Well, I don't object to adding it, but I'm not sure what the use case is
> here? The only time I can remember wanting something like that is when
> I'm filling a buffer with text for test purposes, which is perhaps not a
> compelling use case.
In programming modes, if you need to declare a bunch of variables, you
may duplicate the current line several times and then proceed to rename
them. I see the proposed new command may be useful in that scenario.
Also, why not name the command `duplicate-line'? I think it's a more
descriptive name and more discoverable via apropos (along with
`delete-duplicate-lines', for example).
This has been a hot topic in Q&A sites:
https://stackoverflow.com/questions/88399/how-do-i-duplicate-a-whole-line-in-emacs
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sat, 20 Feb 2021 06:55:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> Cc: 46621 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
> Date: Fri, 19 Feb 2021 21:27:09 +0100
> From: Daniel Martín via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> > Well, I don't object to adding it, but I'm not sure what the use case is
> > here? The only time I can remember wanting something like that is when
> > I'm filling a buffer with text for test purposes, which is perhaps not a
> > compelling use case.
>
> In programming modes, if you need to declare a bunch of variables, you
> may duplicate the current line several times and then proceed to rename
> them.
I usually use M-/ for that. It makes typing something that you just
typed very easy: just a single character followed by M-/ usually does
the job. This allows me to type just what is needed, without
redundant "renaming".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sat, 20 Feb 2021 06:59:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 46621 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> We seem to be adding this & that simple command
> more & more - perhaps just because it's available
> in other editors?
I agree. Just because we don't need any longer to struggle
to keep Emacs down to 8 megabytes is no reason to add commands
without real demand.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sat, 20 Feb 2021 13:04:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Daniel Martín <mardani29 <at> yahoo.es> writes:
> In programming modes, if you need to declare a bunch of variables, you
> may duplicate the current line several times and then proceed to rename
> them. I see the proposed new command may be useful in that scenario.
Right; makes sense.
> This has been a hot topic in Q&A sites:
> https://stackoverflow.com/questions/88399/how-do-i-duplicate-a-whole-line-in-emacs
OK, so there seems to be some general demand for this command, so I
think we should go ahead and add it, unless somebody strongly objects.
> Also, why not name the command `duplicate-line'? I think it's a more
> descriptive name and more discoverable via apropos (along with
> `delete-duplicate-lines', for example).
That does seem like an even better name for the command. What do you
think, Juri?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sat, 20 Feb 2021 13:06:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I usually use M-/ for that. It makes typing something that you just
> typed very easy: just a single character followed by M-/ usually does
> the job. This allows me to type just what is needed, without
> redundant "renaming".
`dabbrev-expand'? I just tried "emacs -Q" and then `M-/' and Emacs just
beeped at me:
---
user-error: No dynamic expansion for ‘buffer.
’ found
---
(Because "buffer." was the previous word in the *scratch* buffer.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sat, 20 Feb 2021 13:14:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Daniel Martín <mardani29 <at> yahoo.es>,
> 46621 <at> debbugs.gnu.org,
> juri <at> linkov.net
> Date: Sat, 20 Feb 2021 14:05:44 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I usually use M-/ for that. It makes typing something that you just
> > typed very easy: just a single character followed by M-/ usually does
> > the job. This allows me to type just what is needed, without
> > redundant "renaming".
>
> `dabbrev-expand'? I just tried "emacs -Q" and then `M-/' and Emacs just
> beeped at me:
You need to type the beginning of what you want it to complete before
M-/. Try
b M-/
f M-/
f M-/ M-/ M-/
etc.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sat, 20 Feb 2021 13:19:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> You need to type the beginning of what you want it to complete before
> M-/. Try
>
> b M-/
> f M-/
> f M-/ M-/ M-/
>
> etc.
Ah, I see. I've never used that command before. However, this just
copies a single word, and not a line? So a line-copying command still
sounds somewhat useful.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sat, 20 Feb 2021 14:17:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: mardani29 <at> yahoo.es, 46621 <at> debbugs.gnu.org, juri <at> linkov.net
> Date: Sat, 20 Feb 2021 14:18:06 +0100
>
> > b M-/
> > f M-/
> > f M-/ M-/ M-/
> >
> > etc.
>
> Ah, I see. I've never used that command before.
It's a great means to type much less, and not just in programming
modes. When writing email as well, for example.
> However, this just copies a single word, and not a line?
I mentioned M-/ because of this rationale:
> > In programming modes, if you need to declare a bunch of variables, you
> > may duplicate the current line several times and then proceed to rename
> > them.
> In programming modes, if you need to declare a bunch of variables, you
> may duplicate the current line several times and then proceed to rename
> them.
So assume you have this:
ptrdiff_t foobar;
and you want to add this:
ptrdiff_t bazquux;
Instead of copying the "foobar" line and then editing "foobar" into
"bazquux", you can do
p M-/ bazquux;
IOW, instead of copying lines, it usually makes more sense in PL modes
to be able to easily repeat what has been typed recently, because
source lines are rarely exact copies of some other line.
So that use case I think is not the best one to justify this new
command. Which is not to say I object to adding it, just that at
least some people may think they need it because they aren't aware of
some Emacs feature. Because I _never_ in all the years of writing
code felt the need to have such a command.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sat, 20 Feb 2021 14:36:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 46621 <at> debbugs.gnu.org (full text, mbox):
On 20.02.2021 16:15, Eli Zaretskii wrote:
> Which is not to say I object to adding it, just that at
> least some people may think they need it because they aren't aware of
> some Emacs feature. Because I_never_ in all the years of writing
> code felt the need to have such a command.
FWIW, I routinely use copy-from-above-command, most often when writing
tests, when a lot of lines look similar to each other, with minor
variations.
Never felt a need for another variation of it, though.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sat, 20 Feb 2021 18:37:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 46621 <at> debbugs.gnu.org (full text, mbox):
>> In programming modes, if you need to declare a bunch of variables, you
>> may duplicate the current line several times and then proceed to rename
>> them. I see the proposed new command may be useful in that scenario.
>
> Right; makes sense.
>
>> This has been a hot topic in Q&A sites:
>> https://stackoverflow.com/questions/88399/how-do-i-duplicate-a-whole-line-in-emacs
>
> OK, so there seems to be some general demand for this command, so I
> think we should go ahead and add it, unless somebody strongly objects.
Also tired of reading endless discussions on Q&A sites about reinventing
such fundamental feature as duplicating a line.
>> Also, why not name the command `duplicate-line'? I think it's a more
>> descriptive name and more discoverable via apropos (along with
>> `delete-duplicate-lines', for example).
>
> That does seem like an even better name for the command. What do you
> think, Juri?
`duplicate-line' is a better name, but the problem is that is based on the
existing command `copy-from-above-command'. Should they share
the same name prefix? Please decide, I have no opinion on this. :-)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 21 Feb 2021 06:18:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 46621 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> >> In programming modes, if you need to declare a bunch of variables, you
> >> may duplicate the current line several times and then proceed to rename
> >> them. I see the proposed new command may be useful in that scenario.
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.
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?
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 21 Feb 2021 06:22:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 46621 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> >> In programming modes, if you need to declare a bunch of variables, you
> >> may duplicate the current line several times and then proceed to rename
> >> them. I see the proposed new command may be useful in that scenario.
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.
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?
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 21 Feb 2021 08:57:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> > >> In programming modes, if you need to declare a bunch of variables, you
> > >> may duplicate the current line several times and then proceed to rename
> > >> them. I see the proposed new command may be useful in that scenario.
>
> 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.
Let's compare these two solutions. Trying to copy 10 lines:
C-a C-k C-k C-y C-y C-y C-y C-y C-y C-y C-y C-y C-y
and adds an unrequested entry to the kill ring
that the user needs to remove from the kill ring later.
When bound to a short key, it's just
C-12 C-c c
and doesn't change the contents of the kill ring.
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 21 Feb 2021 10:42:02 GMT)
Full text and
rfc822 format available.
Message #53 received at submit <at> debbugs.gnu.org (full text, mbox):
On February 21, 2021 10:54:24 AM GMT+02:00, Juri Linkov <juri <at> linkov.net> wrote:
> > > >> In programming modes, if you need to declare a bunch of
> variables, you
> > > >> may duplicate the current line several times and then proceed
> to rename
> > > >> them. I see the proposed new command may be useful in that
> scenario.
> >
> > 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.
>
> Let's compare these two solutions. Trying to copy 10 lines:
>
> C-a C-k C-k C-y C-y C-y C-y C-y C-y C-y C-y C-y C-y
>
> and adds an unrequested entry to the kill ring
> that the user needs to remove from the kill ring later.
>
> When bound to a short key, it's just
>
> C-12 C-c c
>
> and doesn't change the contents of the kill ring.
What is the use case for an Emacs user to need to copy a line 12 times, and is it frequent enough to justify binding the command to a key, and to C-c key on top of that?
Also, let's not forget that Emacs has keyboard macros, and those can be run with a repeat count.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 21 Feb 2021 10:43:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 21 Feb 2021 13:13:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> What is the use case for an Emacs user to need to copy a line 12
> times, and is it frequent enough to justify binding the command to a
> key, and to C-c key on top of that?
That users are asking about a command like this on stackexchange seems to
indicate that some users would find this useful.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 21 Feb 2021 13:14:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> `duplicate-line' is a better name, but the problem is that is based on the
> existing command `copy-from-above-command'. Should they share
> the same name prefix? Please decide, I have no opinion on this. :-)
I think it's fine to go with `duplicate-line', even if it's conceptually
similar to `copy-from-above-command'.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 21 Feb 2021 13:20:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 46621 <at> debbugs.gnu.org (full text, mbox):
On February 21, 2021 3:12:19 PM GMT+02:00, Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > What is the use case for an Emacs user to need to copy a line 12
> > times, and is it frequent enough to justify binding the command to a
> > key, and to C-c key on top of that?
>
> That users are asking about a command like this on stackexchange seems
> to
> indicate that some users would find this useful.
They asked about making a dozen copies of a line?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 21 Feb 2021 15:52:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> They asked about making a dozen copies of a line?
I don't think anybody asked for a dozen copies in particular.
I think we should add the command, but I'm not convinced it deserves a
default key binding -- we can add that later if it turns out that this
is the break-out most-popular new command in Emacs 28.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 21 Feb 2021 17:07:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Juri Linkov <juri <at> linkov.net>, Richard Stallman <rms <at> gnu.org>,
> 46621 <at> debbugs.gnu.org, mardani29 <at> yahoo.es
> Date: Sun, 21 Feb 2021 16:51:34 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > They asked about making a dozen copies of a line?
>
> I don't think anybody asked for a dozen copies in particular.
Then why did Juri decide to countermand Richard's arguments by a
strawman?
> I think we should add the command, but I'm not convinced it deserves a
> default key binding -- we can add that later if it turns out that this
> is the break-out most-popular new command in Emacs 28.
Richard's arguments still stand, and I'd prefer to seriously consider
rather than dismiss them.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 21 Feb 2021 17:40:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Richard's arguments still stand, and I'd prefer to seriously consider
> rather than dismiss them.
Richard said that he didn't see the point of this command since we have
`C-a C-k C-k'. Nevertheless, it has been demonstrated that this is a
command that users do ask about, so I didn't see any point in repeating
that.
But in the interest of non-dismissal, I've now done so.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 21 Feb 2021 17:42:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> Also, let's not forget that Emacs has keyboard
> macros, and those can be run with a repeat count.
+1 for emphasizing this.
We should maybe emphasize it more, particularly
when someone used to another editor asks why
Emacs doesn't have this or that key/action.
Instead, we too often, I think, start thinking
about whether Emacs should indeed add such a
command (and key).
Newbies, in particular, could do well to learn
about using keyboard macros early.
(I haven't used the tutorial in ages. Do we
introduce recording and playing back macros?)
Speaking of which, it might be good to speak
more of "recording" and "playing back" a
sequence of actions, and less of "macros" in
this context.
I think that many people are used to turning
on "recording" in various contexts - it's not
a big deal as a notion, whereas "macro" sounds
exotic and can sound complicated/intimidating.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 21 Feb 2021 17:46:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> That users are asking about a command like this
> on stackexchange seems to indicate that some
> users would find this useful.
Not necessarily. Which users? Sometimes newbies
to Emacs are looking for what they're used to in
some other editor, and not seeing that in Emacs
they think "missing feature".
And answers on emacs.SE often set newbies straight
in this regard, saying "this is how you use Emacs
to do what you want".
The first response by us shouldn't be a knee-jerk
reaction to add what someone says is missing. We
should first check what people who use Emacs do,
i.e., see if what seems to be missing really
represents a problem to be fixed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 21 Feb 2021 18:01:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> I think we should add the command, but I'm not convinced it deserves a
> default key binding
I'd support that. Doesn't hurt; anyone can
make use of it. Not a big deal.
> we can add that later if it turns out that this
> is the break-out most-popular new command in Emacs 28.
I'd hope that we'd hold off for quite a while,
and real, popular acclaim.
It's trivial for users to bind a command. And
users will let Emacs know if they really, really
want a default binding for some command. Be
conservative handing out keys by default.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 21 Feb 2021 21:14:02 GMT)
Full text and
rfc822 format available.
Message #86 received at submit <at> debbugs.gnu.org (full text, mbox):
>> > 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.
>>
>> Let's compare these two solutions. Trying to copy 10 lines:
>>
>> C-a C-k C-k C-y C-y C-y C-y C-y C-y C-y C-y C-y C-y
>>
>> and adds an unrequested entry to the kill ring
>> that the user needs to remove from the kill ring later.
>>
>> When bound to a short key, it's just
>>
>> C-12 C-c c
>>
>> and doesn't change the contents of the kill ring.
>
> What is the use case for an Emacs user to need to copy a line 12
> times, and is it frequent enough
Yes, it is frequently used, as these Q&A sites indicate.
> to justify binding the command to a key, and to C-c key on top
> of that?
ISTR, 'C-c letter' keys are reserved for users, so users can bind the
command to 'C-c c' or any other short key. But I can't prove if such
convention of 'C-c letter' for user keys really exists, I can't find it
in the manual.
Or it could be bound to some short key sequence by default.
Even without a keybinding the key sequence is very short:
M-10 M-x dup RET
> Also, let's not forget that Emacs has keyboard macros, and those can
> be run with a repeat count.
This is how long it takes with keyboard macros:
C-a C-k C-k C-x ( C-y C-x ) C-10 C-x e
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 21 Feb 2021 21:14:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 21 Feb 2021 22:07:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> I can't prove if such convention of 'C-c letter' for
> user keys really exists, I can't find it in the manual.
In the Elisp manual, `i key bind TAB':
key binding
key binding, conventions for
Or `i conven TAB': (with substring matching):
buffer display conventions
coding conventions in Emacs Lisp
comments, Lisp convention for
conventions for writing major modes
conventions for writing minor modes
documentation conventions
documentation strings, conventions and tips
key binding, conventions for
major mode conventions
minor mode conventions
programming conventions
set-advertised-calling-convention
typographic conventions
(Yet another advertisement for completion candidates
as an aid to discovery.)
Candidate `key binding, conventions for' takes you
to node `Key Binding Conventions', where you find
this, among other conventions:
Don't define 'C-c LETTER' as a key in Lisp programs.
Sequences consisting of 'C-c' and a letter (either
upper or lower case) are reserved for users; they
are the *only* sequences reserved for users, so do
not block them.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 21 Feb 2021 23:05:01 GMT)
Full text and
rfc822 format available.
Message #95 received at submit <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Mon, 22 Feb 2021 06:23:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 46621 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > What is the use case for an Emacs user to need to copy a line 12
> > times, and is it frequent enough to justify binding the command to a
> > key, and to C-c key on top of that?
> That users are asking about a command like this on stackexchange seems to
> indicate that some users would find this useful.
Sure, but how much? Is it enough interest that we should cater to it?
Adding to Emacs every function or command that some users would like
would make it even more bloated. Of course, we add commands, but we
should make sure each one is substantially useful.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Mon, 22 Feb 2021 06:24:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 46621 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > 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.
> Let's compare these two solutions. Trying to copy 10 lines:
> C-a C-k C-k C-y C-y C-y C-y C-y C-y C-y C-y C-y C-y
> and adds an unrequested entry to the kill ring
> that the user needs to remove from the kill ring later.
With my proposd change to C-y, it would be
C-a C-k C-k C-u 12 C-y
and it would not require the user to make a new key binding.
Changing the contents of the kill ring is not a drawback.
It is the normal way you move text around in Emacs.
> It's not realistic to change the meaning of the numeric arg to C-y.
> People already use the current meaning for decades.
We could inquire of the users to see what they think about the issue.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Mon, 22 Feb 2021 09:42:01 GMT)
Full text and
rfc822 format available.
Message #104 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> > It's not realistic to change the meaning of the numeric arg to C-y.
> > People already use the current meaning for decades.
>
> We could inquire of the users to see what they think about the issue.
Every once in a while the lack of such fundamental command sparks very
long discussions how to reinvent the wheel. Some recent examples:
https://stackoverflow.com/questions/88399/how-do-i-duplicate-a-whole-line-in-emacs
https://stackoverflow.com/questions/88399/how-do-i-duplicate-a-whole-line-in-emacs?page=2
https://stackoverflow.com/questions/27129147/efficent-way-to-copy-and-paste-a-line
https://stackoverflow.com/questions/12132601/duplicating-the-current-line
https://emacs.stackexchange.com/questions/22705/quickly-duplicate-line-and-increase-number-for-lots-of-lines
https://old.reddit.com/r/emacs/comments/lkyadp/weekly_tipstricketc_thread/gnnniq3/
https://old.reddit.com/r/emacs/comments/jvpccf/weekly_tipstricketc_thread/gcr8h68/
https://old.reddit.com/r/emacs/comments/jwhr6g/batteries_included_with_emacs/gcqdmp9/
with questions like from the last:
Why does emacs doesn't have a built-in ergonomic way to duplicate a line?
Genuinely curious, seems like something fundamental. Guess it is one of
the reasons evil-mode has rise so much. Any new comer will feel disgusted
by having to do C-a C-space C-e M-w and more keystrokes to place it
The proposed tiny 8-line patch was intended to help people avoid
wasting their time on such trivial things.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Mon, 22 Feb 2021 15:44:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Date: Mon, 22 Feb 2021 11:07:58 +0200
> Cc: 46621 <at> debbugs.gnu.org, larsi <at> gnus.org, mardani29 <at> yahoo.es
>
> > > It's not realistic to change the meaning of the numeric arg to C-y.
> > > People already use the current meaning for decades.
> >
> > We could inquire of the users to see what they think about the issue.
>
> Every once in a while the lack of such fundamental command sparks very
> long discussions how to reinvent the wheel. Some recent examples:
Thanks for the links.
However, I don't think they add anything substantial to this
discussion. For starters, many posters there just wanted to know how
many keystrokes it takes in Emacs to copy a line, and some even said
they wanted to compare the result with Vim. They don't necessarily
ask for a command or a single short key sequence to do that, at least
not in every post.
More importantly, I see no description of the situations where such a
copy is needed, so it is hard to analyze reason about the necessity.
For example, perhaps some of the posters wanted this because they are
unaware of some existing Emacs features which can do the job
efficiently enough.
This is why I asked here to describe the use cases, i.e. the
situations where such a command would be needed. I didn't get any
answers to that, AFAIR. Just one person posted his experiences.
Without knowing what situations necessitate such a command, I don't
see how we will be able to reason whether the needs justify adding the
command. And reason we must, because we cannot possibly implement
feature after feature just because someone asks about it on
stackexchange.
> The proposed tiny 8-line patch was intended to help people avoid
> wasting their time on such trivial things.
Yes, this command is relatively small. But we must have some criteria
for adding new commands and features, because otherwise we will add 8
lines, then another 10 lines, then 5 more, etc. etc. These things add
up, and that's even before you consider the supporting docs and other
consequences.
Bottom line, if we want to consider this command, we should somehow
come up with the relevant use cases, and then weigh them against the
added complexity and maintenance costs. I therefore urge people who
think they know these details to please speak up and contribute to
this discussion.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Mon, 22 Feb 2021 15:46:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: bug-gnu-emacs <at> gnu.org, Richard Stallman <rms <at> gnu.org>,
> 46621 <at> debbugs.gnu.org, larsi <at> gnus.org, mardani29 <at> yahoo.es
> Date: Sun, 21 Feb 2021 22:37:28 +0200
>
> > Also, let's not forget that Emacs has keyboard macros, and those can
> > be run with a repeat count.
>
> This is how long it takes with keyboard macros:
>
> C-a C-k C-k C-x ( C-y C-x ) C-10 C-x e
But that's a one-time investment. Thereafter one can bind this to a
key and save it to the init file.
So counting the keystrokes required for defining the macro is not
unlike counting keystrokes required for coding the function you
propose.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Mon, 22 Feb 2021 16:30:01 GMT)
Full text and
rfc822 format available.
Message #113 received at submit <at> debbugs.gnu.org (full text, mbox):
On Mon, Feb 22 2021, Eli Zaretskii wrote:
> More importantly, I see no description of the situations where such a
> copy is needed, so it is hard to analyze reason about the necessity.
One example where copy-line would be useful is editing configuration
files. E.g. /etc/ssh/sshd_config list many options with the default
value but as comments, like so:
#SyslogFacility AUTH
#LogLevel INFO
... other options ...
Now, if I want to change LogLevel to say DEBUG, I would copy the line,
keep the original, and edit the copied line.
Not hard to do in Emacs, but somehow the vi way of doing this feels more
efficient.
Helmut
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Mon, 22 Feb 2021 16:59:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 46621 <at> debbugs.gnu.org (full text, mbox):
On Feb 22 2021, Helmut Eller wrote:
> On Mon, Feb 22 2021, Eli Zaretskii wrote:
>
>> More importantly, I see no description of the situations where such a
>> copy is needed, so it is hard to analyze reason about the necessity.
>
> One example where copy-line would be useful is editing configuration
> files. E.g. /etc/ssh/sshd_config list many options with the default
> value but as comments, like so:
>
> #SyslogFacility AUTH
> #LogLevel INFO
> ... other options ...
>
> Now, if I want to change LogLevel to say DEBUG, I would copy the line,
> keep the original, and edit the copied line.
But you don't need the repeat count for that. copy-from-above-command
will work well for this task.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Mon, 22 Feb 2021 17:05:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 46621 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> Bottom line, if we want to consider this command, we should somehow come
> up with the relevant use cases, and then weigh them against the added
> complexity and maintenance costs. I therefore urge people who think
> they know these details to please speak up and contribute to this
> discussion.
>
My 2 cents: a typical case where this could be useful is:
switch (foobar) {
case long_enum_value_name_a: printf ("a"); break;
case long_enum_value_name_b: printf ("b"); break;
case long_enum_value_name_c: printf ("c"); break;
case long_enum_value_name_d: printf ("d"); break;
case long_enum_value_name_e: printf ("e"); break;
case long_enum_value_name_f: printf ("f"); break;
case long_enum_value_name_g: printf ("g"); break;
case long_enum_value_name_h: printf ("h"); break;
case long_enum_value_name_i: printf ("i"); break;
default: printf ("?"); break;
}
Another typical case:
import java.util.Set;
import java.util.TreeSet;
import java.util.HashSet;
import java.util.LinkedHashSet;
I agree with Richard that this can be done with C-a C-k C-k C-y..., which
is what I've been using in such cases, but that doesn't mean that the
proposed command wouldn't be welcome. I agree with Juri that Richard's
solution "pollutes" the kill-ring with something that the user actually
did not want to kill. I would suggest the following (based on Juri's
code):
(defun duplicate-line (&optional arg)
(interactive "p")
(save-mark-and-excursion
(dotimes (_ arg)
(forward-line 1)
(insert "\n")
(forward-line -1)
(copy-from-above-command))))
(global-set-key (kbd "C-x r z") 'duplicate-line)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Mon, 22 Feb 2021 17:10:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Date: Mon, 22 Feb 2021 17:28:39 +0100
>
> One example where copy-line would be useful is editing configuration
> files. E.g. /etc/ssh/sshd_config list many options with the default
> value but as comments, like so:
>
> #SyslogFacility AUTH
> #LogLevel INFO
> ... other options ...
>
> Now, if I want to change LogLevel to say DEBUG, I would copy the line,
> keep the original, and edit the copied line.
I already mentioned M-/ as the alternative. In the above case, type
"#L M-/", and Emacs will complete to "#LogLevel". IOW, if these cases
are considered as "repeat a previous word" rather than "copy a
previous line, then edit it", the solution already exists. I suspect
that people who are looking for this command simply don't know about
M-/ in Emacs, because IME it's still quite a unique feature.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Mon, 22 Feb 2021 17:17:03 GMT)
Full text and
rfc822 format available.
Message #125 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 22 Feb 2021 17:04:02 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
>
> My 2 cents: a typical case where this could be useful is:
>
> switch (foobar) {
> case long_enum_value_name_a: printf ("a"); break;
> case long_enum_value_name_b: printf ("b"); break;
> case long_enum_value_name_c: printf ("c"); break;
> case long_enum_value_name_d: printf ("d"); break;
> case long_enum_value_name_e: printf ("e"); break;
> case long_enum_value_name_f: printf ("f"); break;
> case long_enum_value_name_g: printf ("g"); break;
> case long_enum_value_name_h: printf ("h"); break;
> case long_enum_value_name_i: printf ("i"); break;
> default: printf ("?"); break;
> }
Here's how I'd type this:
case long_enum_value_name_a: printf ("a"); break;
c M-/ DEL b : p M-/ ("b"); b M-/
c M-/ DEL c : p M-/ ("c"); b M-/
c M-/ M-/ DEL d : p M-/ ("d"); b M-/
etc. (And if the series are indeed longer than a couple of lines, a
rare case indeed, then a keyboard macro is in order.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Mon, 22 Feb 2021 17:55:01 GMT)
Full text and
rfc822 format available.
Message #128 received at 46621 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> My 2 cents: a typical case where this could be useful is:
>>
>> switch (foobar) {
>> case long_enum_value_name_a: printf ("a"); break;
>> case long_enum_value_name_b: printf ("b"); break;
>> case long_enum_value_name_c: printf ("c"); break;
>> case long_enum_value_name_d: printf ("d"); break;
>> case long_enum_value_name_e: printf ("e"); break;
>> case long_enum_value_name_f: printf ("f"); break;
>> case long_enum_value_name_g: printf ("g"); break;
>> case long_enum_value_name_h: printf ("h"); break;
>> case long_enum_value_name_i: printf ("i"); break;
>> default: printf ("?"); break;
>> }
>
> Here's how I'd type this:
>
> case long_enum_value_name_a: printf ("a"); break;
> c M-/ DEL b : p M-/ ("b"); b M-/
> c M-/ DEL c : p M-/ ("c"); b M-/
> c M-/ M-/ DEL d : p M-/ ("d"); b M-/
>
> etc. (And if the series are indeed longer than a couple of lines, a
> rare case indeed, then a keyboard macro is in order.)
>
Yes, that's one way to do it, perhaps the most "emacsish" way to do it.
But it takes more keystrokes than what you write:
case long_enum_value_name_a: printf ("a"); break; RET
c M-/ SPC l M-/ DEL DEL b : SPC p M-/ SPC ("b"); b M-/ ; RET
c M-/ SPC l M-/ DEL DEL c : SPC p M-/ SPC ("c"); b M-/ ; RET
...
And yes, keyboard macros can also be used.
That doesn't mean that the proposed feature wouldn't be useful; I'd say
it's more intuitive:
case long_enum_value_name_a: printf ("a"); break; RET
C-u 8 C-x r z
C-s a : RET
C-b C-b C-d b
C-n C-b C-d c
C-n C-b C-d d
...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Mon, 22 Feb 2021 18:34:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 46621 <at> debbugs.gnu.org (full text, mbox):
On Mon, Feb 22 2021, Andreas Schwab wrote:
>> One example where copy-line would be useful is editing configuration
>> files. E.g. /etc/ssh/sshd_config list many options with the default
>> value but as comments, like so:
>>
>> #SyslogFacility AUTH
>> #LogLevel INFO
>> ... other options ...
>>
>> Now, if I want to change LogLevel to say DEBUG, I would copy the line,
>> keep the original, and edit the copied line.
>
> But you don't need the repeat count for that. copy-from-above-command
> will work well for this task.
I didn't know about this. But if I place point between LogLevel and
INFO and then execute M-x copy-from-above-command then the result is
#LogLevelcility AUTH INFO
which is not what is needed in this situation.
Helmut
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Mon, 22 Feb 2021 18:43:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 46621 <at> debbugs.gnu.org (full text, mbox):
On Mon, Feb 22 2021, Eli Zaretskii wrote:
>> One example where copy-line would be useful is editing configuration
>> files. E.g. /etc/ssh/sshd_config list many options with the default
>> value but as comments, like so:
>>
>> #SyslogFacility AUTH
>> #LogLevel INFO
>> ... other options ...
>>
>> Now, if I want to change LogLevel to say DEBUG, I would copy the line,
>> keep the original, and edit the copied line.
>
> I already mentioned M-/ as the alternative. In the above case, type
> "#L M-/", and Emacs will complete to "#LogLevel". IOW, if these cases
> are considered as "repeat a previous word" rather than "copy a
> previous line, then edit it", the solution already exists. I suspect
> that people who are looking for this command simply don't know about
> M-/ in Emacs, because IME it's still quite a unique feature.
I certainly know about M-/, but in this situation it's pretty far down
the list of alternatives I would consider. Killing the whole line and
inserting it two times is what I usually end up doing.
Admittedly, I do have my own copy-line command and it's bound to C-x-,.
But I often forget the key binding.
Helmut
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Mon, 22 Feb 2021 19:42:02 GMT)
Full text and
rfc822 format available.
Message #137 received at submit <at> debbugs.gnu.org (full text, mbox):
>> But you don't need the repeat count for that. copy-from-above-command
>> will work well for this task.
>
> I didn't know about this. But if I place point between LogLevel and
> INFO and then execute M-x copy-from-above-command then the result is
>
> #LogLevelcility AUTH INFO
>
> which is not what is needed in this situation.
I never knew about copy-from-above-command either. It's not
bound to any keys. It's not in the emacs manual. I think
it's also named incorrectly.
In emacs terminology it's not copying the text (like to the
kill-ring) but inserting or yanking it into the buffer (just
not from the kill-ring but from the previous line). It seems
closer in concept to how dabbrev and hippie use the term
"expand".
--
Howard
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Mon, 22 Feb 2021 19:47:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Why on earth is this called `copy-from-above-command'?
"-command"?
Maybe it would help to add a more discoverable alias?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Mon, 22 Feb 2021 20:52:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 46621 <at> debbugs.gnu.org (full text, mbox):
On Mon, 22 Feb 2021 17:43:28 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
> Bottom line, if we want to consider this command, we should somehow
> come up with the relevant use cases, and then weigh them against the
> added complexity and maintenance costs. I therefore urge people who
> think they know these details to please speak up and contribute to
> this discussion.
I frequently use the following command (bound to `C-c l'), which suits
my needs better than the proposed command would or dabbrev-expand does:
(defun srb-select-line ()
"Select line at point and copy to kill ring."
(interactive)
(copy-region-as-kill (line-beginning-position) (line-end-position)))
A common use case for me is copying somewhat complex shell commands I
keep stored in a file; they are stored as one liners to be easy to copy.
I don't want them to be immediately yanked into the file and for these
cases I don't need the feature of multiple copies via a prefix argument
(though in some documents I often do want multiple copies of a single
line, but usually at different parts of the document, so then just
yanking at the different locations is better than moving the copies).
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Tue, 23 Feb 2021 19:31:01 GMT)
Full text and
rfc822 format available.
Message #146 received at 46621 <at> debbugs.gnu.org (full text, mbox):
On 22.02.2021 21:46, Drew Adams wrote:
> Why on earth is this called `copy-from-above-command'?
>
> "-command"?
>
> Maybe it would help to add a more discoverable alias?
Both good points.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Fri, 17 Jun 2022 17:35:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> Why there is still no such fundamental command as duplicating the current
> line? This command slightly extends the existing copy-from-above-command:
I've now added this command to Emacs 29 as `duplicate-line'.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug marked as fixed in version 29.1, send any further explanations to
46621 <at> debbugs.gnu.org and Juri Linkov <juri <at> linkov.net>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Fri, 17 Jun 2022 17:35:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sat, 18 Jun 2022 09:33:01 GMT)
Full text and
rfc822 format available.
Message #154 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> I've now added this command to Emacs 29 as `duplicate-line'.
Cool! I've had a similar command defined locally since 2015 (which I've
found so useful over time that I've given it a short global keybinding).
I have some suggestions that I think make the command even more useful:
- Making it more DWIM'y by having it duplicate the region instead when
it's active (perhaps giving it a more general name like
`duplicate-thing`, `duplicate-dwim`, or maybe just `duplicate`).
- Having point end up at the duplicated line instead of the original
one, since that's the line you usually want to edit (in my
experience).
- With a prefix argument, comment out the original line/region after
duplicating it. This is perhaps a bit too specialized to be useful in
general compared to the other two suggestions, though I've found it
very useful personally.
Happy to help if any of these sound eligible for inclusion.
Here's my local definition for reference:
(defun duplicate (arg)
"Duplicate the current line, or region if active.
When called with a prefix argument the current line or region is
commented out before it's copied."
(interactive "P")
(setq arg (or arg 1))
(let ((beg (if (region-active-p)
(region-beginning)
(line-beginning-position)))
(end (if (region-active-p)
(region-end)
(line-end-position)))
(point (point)))
(goto-char end)
(let ((to-duplicate (buffer-substring beg end)))
(when (listp arg)
(comment-region beg end)
(setq arg 1))
(dotimes (_ arg)
(end-of-line)
(newline)
(insert to-duplicate)))
(backward-char (- end point))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sat, 18 Jun 2022 12:57:01 GMT)
Full text and
rfc822 format available.
Message #157 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Simen Heggestøyl <simenheg <at> runbox.com> writes:
>> I've now added this command to Emacs 29 as `duplicate-line'.
>
> Cool! I've had a similar command defined locally since 2015 (which I've
> found so useful over time that I've given it a short global keybinding).
>
> I have some suggestions that I think make the command even more useful:
>
> - Making it more DWIM'y by having it duplicate the region instead when
> it's active (perhaps giving it a more general name like
> `duplicate-thing`, `duplicate-dwim`, or maybe just `duplicate`).
That makes sense, but there are some edge conditions here that the
current implementation avoids by using a "line" definition. That is, if
we're at the final line in the buffer, and there's no newline at the
end, `duplicate-line' will add one. That is, it's really line oriented,
and not region oriented, and making it do regions, too, would possibly
make it more confusing.
Unless we ensure a newline at the end of all the regions we paste in.
> - Having point end up at the duplicated line instead of the original
> one, since that's the line you usually want to edit (in my
> experience).
Yes, that's true.
> - With a prefix argument, comment out the original line/region after
> duplicating it. This is perhaps a bit too specialized to be useful in
> general compared to the other two suggestions, though I've found it
> very useful personally.
I think that sounds a bit too specialised.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sat, 18 Jun 2022 18:04:02 GMT)
Full text and
rfc822 format available.
Message #160 received at 46621 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> I've now added this command to Emacs 29 as `duplicate-line'.
Thank you! There was quite some discussion about generalising the concept last time it came up for discussion, and making it work on the region when active was found to be very useful. It comes quite naturally in use, much like upcase-dwim etc.
The attached patch does that. For extra convenience, when the active region is rectangular it is duplicated to the right, since that is what is usually most convenient.
There's a few subtleties here: the code takes care to preserve the region because the user may want to press the key again for another copy. (This means that we need to use undo-inhibit-region for undo to work properly.)
Do you feel audacious enough for a standard key binding?
[duplicate-line-or-region.diff (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sat, 18 Jun 2022 18:11:02 GMT)
Full text and
rfc822 format available.
Message #163 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> Cc: 46621 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Sat, 18 Jun 2022 20:02:58 +0200
>
> -(defun duplicate-line (&optional n)
> - "Duplicate the current line N times.
> +(defun duplicate-line-or-region (&optional n)
> + "Duplicate the current line or region N times.
There's no need to include "or region" in the command's name and doc
string's first line. We have quite a few commands that are sensitive
to the active region, and work on region when it's active. We just
mention this in the doc string, and that's that.
> +If the region is inactive, the current line is duplicated.
Passive tense alert!
> +Otherwise, duplicate the region's contents. The region remains
> +active afterwards.
> +If the region is rectangular, duplication is made on its right-hand side.
Another one!
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 19 Jun 2022 11:44:01 GMT)
Full text and
rfc822 format available.
Message #166 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattiase <at> acm.org> writes:
>> I've now added this command to Emacs 29 as `duplicate-line'.
>
> Thank you! There was quite some discussion about generalising the
> concept last time it came up for discussion, and making it work on the
> region when active was found to be very useful. It comes quite
> naturally in use, much like upcase-dwim etc.
>
> The attached patch does that. For extra convenience, when the active
> region is rectangular it is duplicated to the right, since that is
> what is usually most convenient.
Simen proposed something quite similar (added to the CCs), and my only
objection was that the semantics of the simpler command is quite
clear -- it always creates a new line, even if we're at a final line in
a buffer without a newline. When dealing with regions, it's not quite
clear what the semantics should be in those corner cases (i.e., regions
that doesn't end with a newline)...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 19 Jun 2022 15:03:02 GMT)
Full text and
rfc822 format available.
Message #169 received at 46621 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
18 juni 2022 kl. 20.09 skrev Eli Zaretskii <eliz <at> gnu.org>:
> There's no need to include "or region" in the command's name and doc
> string's first line.
Changed.
> Passive tense alert!
> Another one!
Both changed.
Thanks for the comments!
The attached patch now handles rectangle duplication better. (Rectangular regions are nice to use but can be surprisingly unpleasant to program with.)
That code was moved to rect.el where it probably belongs.
There will be tests as well.
[duplicate-line.diff (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 19 Jun 2022 15:21:02 GMT)
Full text and
rfc822 format available.
Message #172 received at 46621 <at> debbugs.gnu.org (full text, mbox):
19 juni 2022 kl. 13.43 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:
> Simen proposed something quite similar (added to the CCs), and my only
> objection was that the semantics of the simpler command is quite
> clear -- it always creates a new line, even if we're at a final line in
> a buffer without a newline.
Actually shouldn't duplicating such a line add a newline + a copy of the current line with no terminal newline? Right now the copy is always newline-terminated even if the original wasn't, which seems a bit inconsistent. What do you think?
> When dealing with regions, it's not quite
> clear what the semantics should be in those corner cases (i.e., regions
> that doesn't end with a newline)...
Not much of a edge case, is it? If you select "bon" and duplicate you end up with "bonbon", as promised.
Region-sensitive commands are useful since they multiplex functionality on the same keys without added cognitive load. (It's high time we rebound M-u to upcase-dwim etc.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 19 Jun 2022 15:23:01 GMT)
Full text and
rfc822 format available.
Message #175 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattiase <at> acm.org> writes:
> Actually shouldn't duplicating such a line add a newline + a copy of
> the current line with no terminal newline? Right now the copy is
> always newline-terminated even if the original wasn't, which seems a
> bit inconsistent. What do you think?
No, it's consistent -- it always creates a new line.
>> When dealing with regions, it's not quite
>> clear what the semantics should be in those corner cases (i.e., regions
>> that doesn't end with a newline)...
>
> Not much of a edge case, is it? If you select "bon" and duplicate you
> end up with "bonbon", as promised.
It's edgy compared to what it's supposed to be doing -- duplicating
lines.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Mon, 20 Jun 2022 09:27:01 GMT)
Full text and
rfc822 format available.
Message #178 received at 46621 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
19 juni 2022 kl. 17.22 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:
> No, it's consistent -- it always creates a new line.
Either behaviour can be seen as consistent. I suppose it's a matter of what behaviour we find more convenient.
It's expected to be a rare case and I have no strong opinion about it.
> It's edgy compared to what it's supposed to be doing -- duplicating
> lines.
Well, now it does more. Do you mean that you prefer it wouldn't, or that we change the name?
I have no strong opinion about the name but it would be a shame to make the command less useful.
Here is an updated patch that fixes a bug in the original code (would crash when called without an argument) and adds tests.
[0001-Make-duplicate-line-work-on-regions-bug-46621.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Mon, 20 Jun 2022 18:30:02 GMT)
Full text and
rfc822 format available.
Message #181 received at 46621 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > Why there is still no such fundamental command as duplicating the current
> > line? This command slightly extends the existing copy-from-above-command:
there is nothng "fundamenal" about that operation. It's one special case
of a general operation. The traditional way to do it in Emacs is
C-p C-a C-k C-k C-y C-y.
Every user who can do basic editing in Emacs knows how to do this,
and givem how (n)frequent this operation is, that's short enough.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Tue, 21 Jun 2022 10:37:02 GMT)
Full text and
rfc822 format available.
Message #184 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattiase <at> acm.org> writes:
>> It's edgy compared to what it's supposed to be doing -- duplicating
>> lines.
>
> Well, now it does more. Do you mean that you prefer it wouldn't, or
> that we change the name?
> I have no strong opinion about the name but it would be a shame to
> make the command less useful.
I found the concept of "an easy command to duplicate the current line a
number of times" to be slightly useful in general, but I'm not sure
about whether extending it to regions makes much sense. If you have a
region already, then `M-w C-y' will be more convenient to say, anyway.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Tue, 21 Jun 2022 11:14:02 GMT)
Full text and
rfc822 format available.
Message #187 received at 46621 <at> debbugs.gnu.org (full text, mbox):
21 juni 2022 kl. 12.35 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:
> If you have a region already, then `M-w C-y' will be more convenient to say
Two commands are not necessarily more convenient than one command.
There is also the advantage of not disturbing the kill ring.
(And for rectangular regions the benefit of a duplication command is even greater.)
There does not seem to be any significant benefit from omitting the region-sensitive behaviour.
We could add `duplicate-dwim` as a separate command but then there would be no reason to use the neutered variant, would there?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Tue, 21 Jun 2022 18:11:02 GMT)
Full text and
rfc822 format available.
Message #190 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> I found the concept of "an easy command to duplicate the current line a
> number of times" to be slightly useful in general, but I'm not sure
> about whether extending it to regions makes much sense. If you have a
> region already, then `M-w C-y' will be more convenient to say, anyway.
This would also mean that the problem is a missing command that
saves the current line to the kill-ring? If such a command existed,
then duplicating the line would take two keys as well: the first
key to save the current line to the kill-ring, and the second key
to yank it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Wed, 22 Jun 2022 04:09:02 GMT)
Full text and
rfc822 format available.
Message #193 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> This would also mean that the problem is a missing command that
> saves the current line to the kill-ring? If such a command existed,
> then duplicating the line would take two keys as well: the first
> key to save the current line to the kill-ring, and the second key
> to yank it.
A command to save the current line to the kill ring might be nice (if it
settles on some definition of "line"), but it doesn't really offer the
convenience.
To insert a copy of a region: `M-w C-y'.
To insert a copy of the current line with such a command: `NEW-COMMAND
C-n' (see if you landed on the next line or whether that took you to the
end of the buffer) `RET'/`C-a' `C-y'.
I.e., `duplicate-line' offers both a practical and mental simplification
over what we have today, but making that command do region stuff doesn't
really give anything except muddling up the command semantics.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Wed, 22 Jun 2022 04:12:02 GMT)
Full text and
rfc822 format available.
Message #196 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattiase <at> acm.org> writes:
> There does not seem to be any significant benefit from omitting the
> region-sensitive behaviour.
The benefit of adding the region sensitive behaviour seems even
slighter, and the problem is, as I said, that it subverts the
(currently) clear semantics the new command has.
For instance, if you mark one and a half line, and say `C-u 5 M-x
duplicate-line', you'll get something that nobody wants -- ever. There
might be some utility if the region version also worked on lines -- that
is, it inserts that it only inserts new complete lines.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Wed, 22 Jun 2022 07:53:01 GMT)
Full text and
rfc822 format available.
Message #199 received at 46621 <at> debbugs.gnu.org (full text, mbox):
>> This would also mean that the problem is a missing command that
>> saves the current line to the kill-ring? If such a command existed,
>> then duplicating the line would take two keys as well: the first
>> key to save the current line to the kill-ring, and the second key
>> to yank it.
>
> A command to save the current line to the kill ring might be nice (if it
> settles on some definition of "line"), but it doesn't really offer the
> convenience.
>
> To insert a copy of a region: `M-w C-y'.
>
> To insert a copy of the current line with such a command: `NEW-COMMAND
> C-n' (see if you landed on the next line or whether that took you to the
> end of the buffer) `RET'/`C-a' `C-y'.
Now I realized what's actually missing is a command `mark-line'.
After marking the line it could move point to the beginning of the next line.
Then the key sequence would be `mark-line M-w C-y'. And the case of
a missing training newline is very rare, so an extra RET is not a problem.
> I.e., `duplicate-line' offers both a practical and mental simplification
> over what we have today, but making that command do region stuff doesn't
> really give anything except muddling up the command semantics.
The above suggestion is just an alternative way to do the same.
BTW, what do you think about the already suggested leaving point
at the end of duplicated lines? This means removing save-excursion
and adding backward-char to the end of `duplicate-line' to move point
before the last newline.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Wed, 22 Jun 2022 07:55:01 GMT)
Full text and
rfc822 format available.
Message #202 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> BTW, what do you think about the already suggested leaving point
> at the end of duplicated lines? This means removing save-excursion
> and adding backward-char to the end of `duplicate-line' to move point
> before the last newline.
It was also suggested to leave point at the start of the duplicated
lines. I think that makes more sense -- the use case here is to copy
lines so that you can start altering them, after all.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Wed, 22 Jun 2022 14:11:02 GMT)
Full text and
rfc822 format available.
Message #205 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> Now I realized what's actually missing is a command `mark-line'.
About a decade ago I added command `mark-line' to my
ad hoc library `misc-cmds.el', with this comment:
;; Probably not very useful.
And yeah, IMO it's not very useful (for me, at least).
> After marking the line it could move point to the
> beginning of the next line.
FWIW, my version moves to the end of the marked line.
IOW, it marks only the line, not its trailing newline.
(defun mark-line (&optional arg)
"Put mark at end of line, point at beginning.
A numeric prefix arg means move forward (backward if negative) that
many lines, thus marking a line other than the one point was
originally in."
(interactive "P")
(setq arg (if arg (prefix-numeric-value arg) 0))
(let ((inhibit-field-motion t))
(forward-line arg)
(push-mark nil t t)
(goto-char (line-end-position))))
> Then the key sequence would be `mark-line M-w C-y'. And the case of
> a missing trai[l]ing newline is very rare, so an extra RET is not a
> problem.
>
> > I.e., `duplicate-line' offers both a practical and
> > mental simplification over what we have today,
Bof.
> > but making that command do region stuff doesn't
> > really give anything except muddling up the command semantics.
>
> The above suggestion is just an alternative way to do the same.
>
> BTW, what do you think about the already suggested leaving point
> at the end of duplicated lines? This means removing save-excursion
> and adding backward-char to the end of `duplicate-line' to move point
> before the last newline.
IMO, it's fine to add any commands you like,
whatever their general use(ful|less)ness.
But please don't succumb to giving them key
bindings just because some new contributor
requested them. Even if you feel you want
to encourage new participants, that's not
appropriate. (My impression is that this is
in fact sometimes a thing with Emacs dev.)
Emacs has gotten along quite well for a very
long time without feeling the crying need
for a `duplicate-line', a `copy-line' or a
`mark-line' command. Maybe ask yourself why.
Just imagine that some such request doesn't
come from a new contributor - treat it as
you would from a longtime participant.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Wed, 22 Jun 2022 17:22:02 GMT)
Full text and
rfc822 format available.
Message #208 received at submit <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>> BTW, what do you think about the already suggested leaving point
>> at the end of duplicated lines? This means removing save-excursion
>> and adding backward-char to the end of `duplicate-line' to move point
>> before the last newline.
>
> It was also suggested to leave point at the start of the duplicated
> lines. I think that makes more sense -- the use case here is to copy
> lines so that you can start altering them, after all.
Behaviour could be different, depending upon what programming construct
your are in. For example, in C,
#include <a.h>
#include <b.h>
...
if I have to include a new library I’ll go to line-no 2 call
duplicate-line and then I want the point at the end. But in the
following lines, I want the opposite behaviour if I want to declare a
variables of other types.
int a1, b1, c1
float a2, b2, c2
// now I want variables of type char
In this case I want the cursor at beginning.
But I feel that former is more useful i.e. point at the end. Think of
different types of statements in a programming language.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Wed, 22 Jun 2022 17:28:02 GMT)
Full text and
rfc822 format available.
Message #211 received at submit <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
> But please don't succumb to giving them key
> bindings just because some new contributor
> requested them. Even if you feel you want
> to encourage new participants, that's not
> appropriate. (My impression is that this is
> in fact sometimes a thing with Emacs dev.)
>
> Emacs has gotten along quite well for a very
> long time without feeling the crying need
> for a `duplicate-line', a `copy-line' or a
> `mark-line' command. Maybe ask yourself why.
>
> Just imagine that some such request doesn't
> come from a new contributor - treat it as
> you would from a longtime participant.
I agree. But please, maintainers, keep the duplicate-line command. :-)
I have started using it 2 days back and I might have used it 100s of
times already. Really useful.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Wed, 22 Jun 2022 18:38:01 GMT)
Full text and
rfc822 format available.
Message #214 received at 46621 <at> debbugs.gnu.org (full text, mbox):
>>> BTW, what do you think about the already suggested leaving point
>>> at the end of duplicated lines? This means removing save-excursion
>>> and adding backward-char to the end of `duplicate-line' to move point
>>> before the last newline.
>>
>> It was also suggested to leave point at the start of the duplicated
>> lines. I think that makes more sense -- the use case here is to copy
>> lines so that you can start altering them, after all.
>
> Behaviour could be different, depending upon what programming construct
> your are in. For example, in C,
>
> #include <a.h>
> #include <b.h>
> ...
>
> if I have to include a new library I’ll go to line-no 2 call
> duplicate-line and then I want the point at the end. But in the
> following lines, I want the opposite behaviour if I want to declare a
> variables of other types.
>
> int a1, b1, c1
> float a2, b2, c2
> // now I want variables of type char
>
> In this case I want the cursor at beginning.
>
> But I feel that former is more useful i.e. point at the end. Think of
> different types of statements in a programming language.
It seems in both cases you expect point to be at the duplicated line,
either at the beginning or the end of the duplicated line. But the
problem is that currently point stays at the original line.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Wed, 22 Jun 2022 18:46:02 GMT)
Full text and
rfc822 format available.
Message #217 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> It seems in both cases you expect point to be at the duplicated line,
> either at the beginning or the end of the duplicated line. But the
> problem is that currently point stays at the original line.
Everybody agrees that that should be fixed. I haven't done so yet
because people are submitting patches to the function, and I don't want
to get in the way of those.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Wed, 22 Jun 2022 20:45:02 GMT)
Full text and
rfc822 format available.
Message #220 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sat 18 Jun 2022 at 08:02pm +02, Mattias Engdegård wrote:
> Do you feel audacious enough for a standard key binding?
Just to put it out there, if the result of the current discussion is
that point is left at the beginning of the upper of the two lines, then
using it would feel like using C-o, so duplicate-line could go on M-o.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Wed, 22 Jun 2022 20:51:02 GMT)
Full text and
rfc822 format available.
Message #223 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> > Do you feel audacious enough for a standard key binding?
>
> Just to put it out there, if the result of the current discussion is
> that point is left at the beginning of the upper of the two lines, then
> using it would feel like using C-o, so duplicate-line could go on M-o.
Please don't give this command a default key binding.
There are a zillion commands that deserve a default
binding more than this one does. And nearly all of
those zillion also don't need a default binding.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 23 Jun 2022 05:48:01 GMT)
Full text and
rfc822 format available.
Message #226 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> Resent-Sender: help-debbugs <at> gnu.org
> Cc: 46621 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Wed, 22 Jun 2022 13:44:31 -0700
>
> Just to put it out there, if the result of the current discussion is
> that point is left at the beginning of the upper of the two lines, then
> using it would feel like using C-o, so duplicate-line could go on M-o.
Which will be one more blow to those who don't want to lose facemenu,
to whom we told just one major release ago they can get the old
behavior back by binding M-o to facemenu-keymap. If we usurp M-o now,
that recipe in NEWS.28 will no longer be completely accurate.
Full disclosure: I'm one of those who happen to like facemenu-keymap
on M-o.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 23 Jun 2022 07:50:02 GMT)
Full text and
rfc822 format available.
Message #229 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Pankaj Jangid <pankaj <at> codeisgreat.org> writes:
> Behaviour could be different, depending upon what programming construct
> your are in. For example, in C,
>
> #include <a.h>
> #include <b.h>
> ...
>
> if I have to include a new library I’ll go to line-no 2 call
> duplicate-line and then I want the point at the end.
But why do you want point at the end? You want to edit those duplicated
lines, presumably.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 23 Jun 2022 08:09:01 GMT)
Full text and
rfc822 format available.
Message #232 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>> Behaviour could be different, depending upon what programming construct
>> your are in. For example, in C,
>>
>> #include <a.h>
>> #include <b.h>
>> ...
>>
>> if I have to include a new library I’ll go to line-no 2 call
>> duplicate-line and then I want the point at the end.
>
> But why do you want point at the end? You want to edit those duplicated
> lines, presumably.
Yes I want to edit it from the end. Beginning of the statement is mostly
common, I just want to replace "b.h>" with "c.h>".
In some languages (like Java), it is even more required because the class
hierarchy is usually very deep. For example,
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Configurable;
and now I want to import "Value" or "Required" class from the same
package. So I would like to do,
M-x duplicate-line RET M-<backspace> V a l u e ;
And repeating would be even more easier,
M-x RET M-<backspace> R e q u i r e d ;
If the pointer is at the beginning then it might be slightly
inconvenient.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 23 Jun 2022 08:18:02 GMT)
Full text and
rfc822 format available.
Message #235 received at 46621 <at> debbugs.gnu.org (full text, mbox):
On Jun 23 2022, Pankaj Jangid wrote:
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>>> Behaviour could be different, depending upon what programming construct
>>> your are in. For example, in C,
>>>
>>> #include <a.h>
>>> #include <b.h>
>>> ...
>>>
>>> if I have to include a new library I’ll go to line-no 2 call
>>> duplicate-line and then I want the point at the end.
>>
>> But why do you want point at the end? You want to edit those duplicated
>> lines, presumably.
>
> Yes I want to edit it from the end.
duplicate-line should keep point at the same column.
--
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 23 Jun 2022 09:06:01 GMT)
Full text and
rfc822 format available.
Message #238 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Pankaj Jangid <pankaj <at> codeisgreat.org> writes:
>> But why do you want point at the end? You want to edit those duplicated
>> lines, presumably.
>
> Yes I want to edit it from the end. Beginning of the statement is mostly
> common, I just want to replace "b.h>" with "c.h>".
"The end" here would be after the final duplicate line -- not at the end
of the final duplicated line, though. So I think that putting it at the
start of the duplicated lines would make more sense even here.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 23 Jun 2022 09:06:01 GMT)
Full text and
rfc822 format available.
Message #241 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> suse.de> writes:
> duplicate-line should keep point at the same column.
Ah, yes, that might be nice...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 23 Jun 2022 09:23:02 GMT)
Full text and
rfc822 format available.
Message #244 received at 46621 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 23 Jun 2022 10:17:04 +0200, Andreas Schwab <schwab <at> suse.de> said:
Andreas> On Jun 23 2022, Pankaj Jangid wrote:
>> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>>
>>>> Behaviour could be different, depending upon what programming construct
>>>> your are in. For example, in C,
>>>>
>>>> #include <a.h>
>>>> #include <b.h>
>>>> ...
>>>>
>>>> if I have to include a new library I’ll go to line-no 2 call
>>>> duplicate-line and then I want the point at the end.
>>>
>>> But why do you want point at the end? You want to edit those duplicated
>>> lines, presumably.
>>
>> Yes I want to edit it from the end.
Andreas> duplicate-line should keep point at the same column.
duplicate-line-pre-hook and duplicate-line-post-hook anyone? 😛
Seriously, itʼs a primitive operation, so Andreas is right. Anyone who
wants to customize the behaviour can advise it.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 23 Jun 2022 11:13:02 GMT)
Full text and
rfc822 format available.
Message #247 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Pankaj Jangid <pankaj <at> codeisgreat.org> writes:
>
>>> But why do you want point at the end? You want to edit those duplicated
>>> lines, presumably.
>>
>> Yes I want to edit it from the end. Beginning of the statement is mostly
>> common, I just want to replace "b.h>" with "c.h>".
>
> "The end" here would be after the final duplicate line -- not at the end
> of the final duplicated line, though. So I think that putting it at the
> start of the duplicated lines would make more sense even here.
If it is /after/ the final duplicate line than that is not what I was
vouching for. I wanted it /at/ the end.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 23 Jun 2022 11:17:02 GMT)
Full text and
rfc822 format available.
Message #250 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
> Andreas> duplicate-line should keep point at the same column.
>
> duplicate-line-pre-hook and duplicate-line-post-hook anyone? 😛
>
> Seriously, itʼs a primitive operation, so Andreas is right. Anyone who
> wants to customize the behaviour can advise it.
I like Andreas' suggestion also. Now, as I am thinkng, it looks more
natural.
Instead of hooks, how about just a customisation variable?
duplicate-line-point-postion - start, same, end?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 23 Jun 2022 11:35:02 GMT)
Full text and
rfc822 format available.
Message #253 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Pankaj Jangid <pankaj <at> codeisgreat.org> writes:
>> Seriously, itʼs a primitive operation, so Andreas is right. Anyone who
>> wants to customize the behaviour can advise it.
>
> I like Andreas' suggestion also. Now, as I am thinkng, it looks more
> natural.
I think we'll go with that, but note that it basically saves you only
one single key press -- <down>.
> Instead of hooks, how about just a customisation variable?
> duplicate-line-point-postion - start, same, end?
I doubt that'll find much use.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 23 Jun 2022 15:11:02 GMT)
Full text and
rfc822 format available.
Message #256 received at 46621 <at> debbugs.gnu.org (full text, mbox):
22 juni 2022 kl. 09.54 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:
> It was also suggested to leave point at the start of the duplicated
> lines. I think that makes more sense -- the use case here is to copy
> lines so that you can start altering them, after all.
We need experience of how it feels in practice. That is, bind the command to a convenient key in your init.el and try remember to use it while editing. Note where it works as desired and where not.
Some of what I found:
* Having the cursor remain in the same column is very useful as it's usually near the spot to be edited in the original or copied line. Automatically moving it to the beginning or end of the line would make it worse.
* Whether it is better to keep the cursor on the first line (as if duplicating downwards) or the last line (as if duplicating upwards) is less clear. It basically comes down to whether it is more common to want a similar but different line above or below the original line. I weakly favour the current design because it generalises better and it's slightly more convenient to edit a sequence of lines top-down than bottom-up.
* A single-key binding (like H-y but not C-x y) makes quite a difference because that way I can quickly stutter out copies as needed without having to plan ahead and use prefix arguments.
* Rectangle duplication is very useful when editing tables or code with similar structure. Compared to copy-paste, it saves a lot of cursor movement and permits immediate repetition if more than one copy is required.
I would be very interested in your own experience (much more than anyone's theoretical speculation).
> The benefit of adding the region sensitive behaviour seems even
> slighter, and the problem is, as I said, that it subverts the
> (currently) clear semantics the new command has.
It's not an unnatural combination; several other editors have similar commands.
Moreover, even if you don't find the region-sensitive behaviour, others do -- for rectangular regions in particular. Nobody is going to complain that there are functions in Emacs that they don't care to use, especially when they don't take up extra keybindings.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 23 Jun 2022 15:21:01 GMT)
Full text and
rfc822 format available.
Message #259 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattiase <at> acm.org> writes:
> * Having the cursor remain in the same column is very useful as it's
> usually near the spot to be edited in the original or copied
> line. Automatically moving it to the beginning or end of the line
> would make it worse.
[...]
> * A single-key binding (like H-y but not C-x y) makes quite a
> difference because that way I can quickly stutter out copies as needed
> without having to plan ahead and use prefix arguments.
I think that means that it might make sense to keep the command as is
(point movement wise). I.e., if we move point to the duplicated line,
then hitting `H-y' a whole bunch of times would leave point at the final
line.
> Moreover, even if you don't find the region-sensitive behaviour,
> others do -- for rectangular regions in particular. Nobody is going to
> complain that there are functions in Emacs that they don't care to
> use, especially when they don't take up extra keybindings.
If we decide to move to the duplicated line, but keep the same column --
then that makes no sense in a region-sensitive context at all. If you
mark a word and hit `H-y', then there's no way to keep the "current
column".
Unless the region commands are also line-based, so the word is copied to
a new line on its own, then you could keep to the same "column" in the
word.
In short: It makes no sense to mash up these two totally different
things into one command, and people do complain about commands that make
no sense.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 23 Jun 2022 15:48:02 GMT)
Full text and
rfc822 format available.
Message #262 received at submit <at> debbugs.gnu.org (full text, mbox):
> Please don't give this command a default key binding.
>
> There are a zillion commands that deserve a default
> binding more than this one does. And nearly all of
> those zillion also don't need a default binding.
There is are default bindings for transpose-lines and for
count-lines-page. Neither of those seems particularly useful.
Maybe there could be a prefix map for "line commands". Something like
ctl-x-r-map for rectangle commands. Perhaps ctl-x-l-map.
Helmut
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 23 Jun 2022 16:08:01 GMT)
Full text and
rfc822 format available.
Message #265 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Date: Thu, 23 Jun 2022 17:47:18 +0200
>
> > Please don't give this command a default key binding.
> >
> > There are a zillion commands that deserve a default
> > binding more than this one does. And nearly all of
> > those zillion also don't need a default binding.
>
> There is are default bindings for transpose-lines and for
> count-lines-page. Neither of those seems particularly useful.
I use both all the time, so they are definitely very useful to me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 23 Jun 2022 17:01:01 GMT)
Full text and
rfc822 format available.
Message #268 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Thu 23 Jun 2022 at 08:47am +03, Eli Zaretskii wrote:
>> Resent-Sender: help-debbugs <at> gnu.org
>> Cc: 46621 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Date: Wed, 22 Jun 2022 13:44:31 -0700
>>
>> Just to put it out there, if the result of the current discussion is
>> that point is left at the beginning of the upper of the two lines, then
>> using it would feel like using C-o, so duplicate-line could go on M-o.
>
> Which will be one more blow to those who don't want to lose facemenu,
> to whom we told just one major release ago they can get the old
> behavior back by binding M-o to facemenu-keymap. If we usurp M-o now,
> that recipe in NEWS.28 will no longer be completely accurate.
>
> Full disclosure: I'm one of those who happen to like facemenu-keymap
> on M-o.
Maybe it would be good to add M-o to the list of keys explicitly
reserved to end users, in that case?
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 23 Jun 2022 17:39:02 GMT)
Full text and
rfc822 format available.
Message #271 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Thu 23 Jun 2022 at 10:00am -07, Sean Whitton wrote:
> Hello,
>
> On Thu 23 Jun 2022 at 08:47am +03, Eli Zaretskii wrote:
>
>>> Resent-Sender: help-debbugs <at> gnu.org
>>> Cc: 46621 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
>>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>>> Date: Wed, 22 Jun 2022 13:44:31 -0700
>>>
>>> Just to put it out there, if the result of the current discussion is
>>> that point is left at the beginning of the upper of the two lines, then
>>> using it would feel like using C-o, so duplicate-line could go on M-o.
>>
>> Which will be one more blow to those who don't want to lose facemenu,
>> to whom we told just one major release ago they can get the old
>> behavior back by binding M-o to facemenu-keymap. If we usurp M-o now,
>> that recipe in NEWS.28 will no longer be completely accurate.
>>
>> Full disclosure: I'm one of those who happen to like facemenu-keymap
>> on M-o.
>
> Maybe it would be good to add M-o to the list of keys explicitly
> reserved to end users, in that case?
Sorry, re-reading, I think you're saying you think it should remain
unbound for longer but not necessarily indefinitely. In which case it
doesn't make sense to add it to the keybinding conventions.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 23 Jun 2022 17:44:01 GMT)
Full text and
rfc822 format available.
Message #274 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> We need experience of how it feels in practice. That is, bind the
> command to a convenient key in your init.el and try remember to use it
> while editing. Note where it works as desired and where not.
>
> Some of what I found:
>
> * Having the cursor remain in the same column is very useful as it's
> usually near the spot to be edited in the original or copied line.
> Automatically moving it to the beginning or end of the line would make
> it worse.
I agree that keeping the same column would be more useful.
> * Whether it is better to keep the cursor on the first line (as if
> duplicating downwards) or the last line (as if duplicating upwards) is less
> clear. It basically comes down to whether it is more common to want
> a similar but different line above or below the original line. I weakly
> favour the current design because it generalises better and it's slightly
> more convenient to edit a sequence of lines top-down than bottom-up.
Usually I duplicate only 1 line, and in 100% of cases the cursor needs
to be on the copied line to start editing it. But when duplicating
more lines with a prefix arg, often it's expected to have the cursor
on the top copied line to start editing copied lines top-down.
I wonder if this is a common use case.
> * A single-key binding (like H-y but not C-x y) makes quite
> a difference because that way I can quickly stutter out copies as
> needed without having to plan ahead and use prefix arguments.
I don't believe everyone would agree on such short keys.
Maybe better to try finding a key in the 'C-x x' keymap
(that already contains a line-related binding 'C-x x t'
`toggle-truncate-lines').
> * Rectangle duplication is very useful when editing tables or code
> with similar structure. Compared to copy-paste, it saves a lot of
> cursor movement and permits immediate repetition if more than one copy
> is required.
Shouldn't rectangle command be on the 'C-x r' keymap?
There are already copy-rectangle-as-kill and yank-rectangle.
OTOH, it seems 'M-w C-y' already can duplicate rectangle
regions?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 23 Jun 2022 17:47:02 GMT)
Full text and
rfc822 format available.
Message #277 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> > Please don't give this command a default key binding.
> >
> > There are a zillion commands that deserve a default
> > binding more than this one does. And nearly all of
> > those zillion also don't need a default binding.
>
> There is are default bindings for transpose-lines and for
> count-lines-page. Neither of those seems particularly useful.
>
> Maybe there could be a prefix map for "line commands". Something like
> ctl-x-r-map for rectangle commands. Perhaps ctl-x-l-map.
My suggestion, if some people here are intent
on adding new default key bindings, to _not_
discuss and decide that in a bug thread.
Instead, please propose whatever you want on
emacs-devel <at> gnu.org. New default key bindings
deserve discussion/review by a wider audience
than just whoever might be following some bug
thread about the introduction of a new command.
A second suggestion is that a new key binding
not be proposed at all for a new command. In
general, at least.
Instead, wait a while, for _users_ to try the
new command and maybe bind it to different keys.
User input on their experience with commands
and keys is helpful in deciding what should
happen by default.
In general, it's not a good idea to be too eager
to add new default key bindings. Especially
without a basis in real user experience.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 23 Jun 2022 17:50:02 GMT)
Full text and
rfc822 format available.
Message #280 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> > * A single-key binding (like H-y but not C-x y) makes quite
> > a difference because that way I can quickly stutter out copies as
> > needed without having to plan ahead and use prefix arguments.
>
> I don't believe everyone would agree on such short keys.
> Maybe better to try finding a key in the 'C-x x' keymap
> (that already contains a line-related binding 'C-x x t'
> `toggle-truncate-lines').
Please take all proposals of new default key bindings
to emacs-devel.
And I'd suggest not making any suggestions of new
bindings for _new_ commands. That's premature UI
"optimization".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 23 Jun 2022 18:32:01 GMT)
Full text and
rfc822 format available.
Message #283 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: mattiase <at> acm.org, larsi <at> gnus.org, 46621 <at> debbugs.gnu.org, juri <at> linkov.net
> Date: Thu, 23 Jun 2022 10:00:05 -0700
>
> Hello,
>
> On Thu 23 Jun 2022 at 08:47am +03, Eli Zaretskii wrote:
>
> >> Resent-Sender: help-debbugs <at> gnu.org
> >> Cc: 46621 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
> >> From: Sean Whitton <spwhitton <at> spwhitton.name>
> >> Date: Wed, 22 Jun 2022 13:44:31 -0700
> >>
> >> Just to put it out there, if the result of the current discussion is
> >> that point is left at the beginning of the upper of the two lines, then
> >> using it would feel like using C-o, so duplicate-line could go on M-o.
> >
> > Which will be one more blow to those who don't want to lose facemenu,
> > to whom we told just one major release ago they can get the old
> > behavior back by binding M-o to facemenu-keymap. If we usurp M-o now,
> > that recipe in NEWS.28 will no longer be completely accurate.
> >
> > Full disclosure: I'm one of those who happen to like facemenu-keymap
> > on M-o.
>
> Maybe it would be good to add M-o to the list of keys explicitly
> reserved to end users, in that case?
I won't mind.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sat, 25 Jun 2022 16:36:01 GMT)
Full text and
rfc822 format available.
Message #286 received at 46621 <at> debbugs.gnu.org (full text, mbox):
23 juni 2022 kl. 17.20 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:
> I think that means that it might make sense to keep the command as is
> (point movement wise). I.e., if we move point to the duplicated line,
> then hitting `H-y' a whole bunch of times would leave point at the final
> line.
Right. Again, it is slightly more consistent to have it duplicate "below" than "above" so I weakly favour this way of working, but don't take my word for it -- try it out in anger.
> If we decide to move to the duplicated line, but keep the same column --
> then that makes no sense in a region-sensitive context at all. If you
> mark a word and hit `H-y', then there's no way to keep the "current
> column".
That's unavoidable because Emacs's region concept prevents the cursor from moving independently of the selection. (Same goes for most other modern editors although they use a slightly different selection paradigm.)
In no way does this diminish the utility of the command in either of its modes of usage.
> It makes no sense to mash up these two totally different
> things into one command, and people do complain about commands that make
> no sense.
But the semantics do make sense -- let's not look for problems that don't exist. It's like `upcase-dwim`: without an active region it acts on the current word, which is the most practical unit for that operation.
If it helps, call the new command `duplicate-dwim` or just `duplicate`. The user who only uses it to duplicate lines is unlikely to be disturbed by its other ways of functioning.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sat, 25 Jun 2022 16:52:02 GMT)
Full text and
rfc822 format available.
Message #289 received at 46621 <at> debbugs.gnu.org (full text, mbox):
23 juni 2022 kl. 19.35 skrev Juri Linkov <juri <at> linkov.net>:
> Usually I duplicate only 1 line, and in 100% of cases the cursor needs
> to be on the copied line to start editing it. But when duplicating
> more lines with a prefix arg, often it's expected to have the cursor
> on the top copied line to start editing copied lines top-down.
> I wonder if this is a common use case.
If only one duplicate was made then perhaps it doesn't matter that much if the cursor has to be moved down one step before editing? (I don't find it to be 100 % of the cases at all; sometimes I want the modified line to be above the original line, sometimes below.)
>> * A single-key binding (like H-y but not C-x y) makes quite
>> a difference because that way I can quickly stutter out copies as
>> needed without having to plan ahead and use prefix arguments.
>
> I don't believe everyone would agree on such short keys.
Quite the contrary, they definitely would! What they wouldn't agree on is what pre-existing binding to repurpose.
Fortunately there are still a few single-key bindings available.
> Maybe better to try finding a key in the 'C-x x' keymap
> (that already contains a line-related binding 'C-x x t'
> `toggle-truncate-lines').
Unfortunately that removes some of the convenience that the command would bring. I can't see anyone typing `C-x x d` (for example) 3 times in a row to get 3 copies, much less 7 times.
>> * Rectangle duplication is very useful when editing tables or code
>> with similar structure. Compared to copy-paste, it saves a lot of
>> cursor movement and permits immediate repetition if more than one copy
>> is required.
>
> Shouldn't rectangle command be on the 'C-x r' keymap?
No, no special binding should be necessary. That's the point. (Several commands work specially on an active rectangle.)
> There are already copy-rectangle-as-kill and yank-rectangle.
> OTOH, it seems 'M-w C-y' already can duplicate rectangle
> regions?
Not nearly as conveniently. Try it and you'll see.
- You can make another copy immediately without having to move the cursor, just by pressing the key again.
- You keep the marked rectangle for any operation (cut, copy, delete, etc).
- You keep the kill-ring unmodified for your own purposes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sat, 25 Jun 2022 17:49:02 GMT)
Full text and
rfc822 format available.
Message #292 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> > I don't believe everyone would agree on such short keys.
>
> Quite the contrary, they definitely would! What they wouldn't agree on
> is what pre-existing binding to repurpose.
> Fortunately there are still a few single-key bindings available.
>
> > Maybe better to try finding a key in the 'C-x x' keymap
> > (that already contains a line-related binding 'C-x x t'
> > `toggle-truncate-lines').
>
> Unfortunately that removes some of the convenience that the command
> would bring. I can't see anyone typing `C-x x d` (for example) 3 times
> in a row to get 3 copies, much less 7 times.
FWIW, I don't agree that _any_ keys should be bound
by default for such a command.
Do not add a new command and immediately give it a
default key binding. That makes little sense.
Let user experience guide spending/wasting default
keys. Users can bind the command to any key they
like. If it becomes super popular, and if there are
good reasons at that point to give it a default key,
then you can take into account the keys that users
at that point say they like for it.
Emacs has survived well for 40 years without such a
command. Just because someone asks for it now is
not a reason that it deserves a default key binding.
There are tons of keys that deserve bindings before
this one does.
Binding this new command to a default key is just
irrational exuberance.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Mon, 27 Jun 2022 19:48:01 GMT)
Full text and
rfc822 format available.
Message #295 received at 46621 <at> debbugs.gnu.org (full text, mbox):
>> Maybe better to try finding a key in the 'C-x x' keymap
>> (that already contains a line-related binding 'C-x x t'
>> `toggle-truncate-lines').
>
> Unfortunately that removes some of the convenience that the command
> would bring. I can't see anyone typing `C-x x d` (for example) 3
> times in a row to get 3 copies, much less 7 times.
But it accepts a prefix arg, so a shorter key sequence is possible:
`C-3 C-x x d`.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Tue, 28 Jun 2022 08:45:01 GMT)
Full text and
rfc822 format available.
Message #298 received at 46621 <at> debbugs.gnu.org (full text, mbox):
27 juni 2022 kl. 21.40 skrev Juri Linkov <juri <at> linkov.net>:
>> Unfortunately that removes some of the convenience that the command
>> would bring. I can't see anyone typing `C-x x d` (for example) 3
>> times in a row to get 3 copies, much less 7 times.
>
> But it accepts a prefix arg, so a shorter key sequence is possible:
> `C-3 C-x x d`.
That's not nearly as useful: it forces you to plan ahead and know the exact number in advance.
With a single keybinding, you can duplicate once, visually confirm that this is what you want to do, and keep duplicating (possibly even holding the key down to repeat!) until you have the number of copies you want. If you go too far, just undo. In other words, it behaves just like any basic text-editing feature. And all of this is available, with exactly the same key, for regions and rectangles!
None of that is possible with a multi-key binding. If you made too many copies you have to erase them by hand, or undo and restart the process with a new prefix number. All of this adds cognitive load, and each attempt requires a series of keypresses.
(Not all commands benefit equally from having a single-key binding, of course. For example, it would not do much to `kill-buffer`.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Tue, 28 Jun 2022 12:11:02 GMT)
Full text and
rfc822 format available.
Message #301 received at submit <at> debbugs.gnu.org (full text, mbox):
> With a single keybinding, you can duplicate once, visually confirm
> that this is what you want to do, and keep duplicating (possibly even
> holding the key down to repeat!) until you have the number of copies
> you want. If you go too far, just undo. In other words, it behaves
> just like any basic text-editing feature. And all of this is
> available, with exactly the same key, for regions and rectangles!
>
> None of that is possible with a multi-key binding. If you made too
> many copies you have to erase them by hand, or undo and restart the
> process with a new prefix number. All of this adds cognitive load, and
> each attempt requires a series of keypresses.
For this use case 'repeat' seems quite usable:
M-x copy-line C-x z z z z z
or whatever number of zs you need.
Helmut
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Tue, 28 Jun 2022 14:30:02 GMT)
Full text and
rfc822 format available.
Message #304 received at 46621 <at> debbugs.gnu.org (full text, mbox):
> > > In emacs terminology it's not copying the text
> > > (like to the kill-ring) but inserting or yanking
> > > it into the buffer (just not from the kill-ring
> > > but from the previous line). It seems closer in
> > > concept to how dabbrev and hippie use the term
> > > "expand".
This is important, IMO.
The name is awful - not helpful.
> > Why on earth is this called `copy-from-above-command'?
> >
> > "-command"?
> >
> > Maybe it would help to add a more discoverable alias?
>
> Both good points.
The command inserts chars from the previous line at
point. By default it inserts all of the text of the
previous line, starting just above point.
Can we please rename this poorly named command?
E.g. defalias a new name and deprecate the old one.
Do I need to create a separate bug / enhancement
request for this, or could it be taken care of in
this thread?
Maybe a name such as `insert-from-previous-line'?
___
`yank' isn't appropriate in the name, because the
`kill-ring' isn't involved.
`insert' is pretty good, though it might not be
super helpful for discovery.
`duplicate' could maybe be used in the name, but
I'm not sure how. The name shouldn't include both
`duplicate' and `line', as that would be misleading.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 30 Jun 2022 16:33:01 GMT)
Full text and
rfc822 format available.
Message #307 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Hello Lars,
On Thu 23 Jun 2022 at 09:31pm +03, Eli Zaretskii wrote:
>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Cc: mattiase <at> acm.org, larsi <at> gnus.org, 46621 <at> debbugs.gnu.org, juri <at> linkov.net
>> Date: Thu, 23 Jun 2022 10:00:05 -0700
>>
>> Hello,
>>
>> On Thu 23 Jun 2022 at 08:47am +03, Eli Zaretskii wrote:
>>
>> >> Resent-Sender: help-debbugs <at> gnu.org
>> >> Cc: 46621 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
>> >> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> >> Date: Wed, 22 Jun 2022 13:44:31 -0700
>> >>
>> >> Just to put it out there, if the result of the current discussion is
>> >> that point is left at the beginning of the upper of the two lines, then
>> >> using it would feel like using C-o, so duplicate-line could go on M-o.
>> >
>> > Which will be one more blow to those who don't want to lose facemenu,
>> > to whom we told just one major release ago they can get the old
>> > behavior back by binding M-o to facemenu-keymap. If we usurp M-o now,
>> > that recipe in NEWS.28 will no longer be completely accurate.
>> >
>> > Full disclosure: I'm one of those who happen to like facemenu-keymap
>> > on M-o.
>>
>> Maybe it would be good to add M-o to the list of keys explicitly
>> reserved to end users, in that case?
>
> I won't mind.
Do you have any thoughts on this, Lars? I asked you about this shortly
after M-o was unbound, and you said we should wait and see, but as it's
been a year, I wanted to ask again.
I don't especially want to push for M-o to be reserved to end users
myself, but if it is already de facto reserved, I think a lot of people
would be grateful to be given a green light to put something there and
have the confidence it won't ever clash with something useful from
upstream.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Fri, 01 Jul 2022 09:28:02 GMT)
Full text and
rfc822 format available.
Message #310 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Sean Whitton <spwhitton <at> spwhitton.name> writes:
> I don't especially want to push for M-o to be reserved to end users
> myself, but if it is already de facto reserved, I think a lot of people
> would be grateful to be given a green light to put something there and
> have the confidence it won't ever clash with something useful from
> upstream.
I'm not sure, actually. If we come up with a super important new
command that should be a one keystroke long, it'd be nice to have
somewhere to put it. (And `copy-line' is definitely not such a
command.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Fri, 01 Jul 2022 16:35:01 GMT)
Full text and
rfc822 format available.
Message #313 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Fri 01 Jul 2022 at 11:27AM +02, Lars Ingebrigtsen wrote:
> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>
>> I don't especially want to push for M-o to be reserved to end users
>> myself, but if it is already de facto reserved, I think a lot of people
>> would be grateful to be given a green light to put something there and
>> have the confidence it won't ever clash with something useful from
>> upstream.
>
> I'm not sure, actually. If we come up with a super important new
> command that should be a one keystroke long, it'd be nice to have
> somewhere to put it. (And `copy-line' is definitely not such a
> command.)
Makes sense to me.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 03 Jul 2022 17:22:02 GMT)
Full text and
rfc822 format available.
Message #316 received at 46621 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Here is an updated patch. It sounded like Eli was largely happy with it but Lars wanted a change of name?
I don't mind either, but please do tell.
[0001-Make-duplicate-line-work-on-regions-bug-46621.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Mon, 04 Jul 2022 03:26:01 GMT)
Full text and
rfc822 format available.
Message #319 received at submit <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattiase <at> acm.org> writes:
> Here is an updated patch. It sounded like Eli was largely happy with
> it but Lars wanted a change of name? I don't mind either, but please
> do tell.
I feel that duplicate-line and duplicate-region should be separate
commands for the sake of semantics.
May be that we implement duplicate-region as more generic and
duplicate-line as a wrapper around it and just pass the line as
argument. If we do that then users are not required to bind two separate
keys for these. Binding with the generic command will serve the
purpose. And users who prefer to call using M-x can still have the right
semantics.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Tue, 05 Jul 2022 16:05:02 GMT)
Full text and
rfc822 format available.
Message #322 received at 46621 <at> debbugs.gnu.org (full text, mbox):
reopen 46621
stop
Let's keep it open until completely done.
bug No longer marked as fixed in versions 29.1 and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 05 Jul 2022 16:05:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Tue, 05 Jul 2022 16:54:02 GMT)
Full text and
rfc822 format available.
Message #327 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattiase <at> acm.org> writes:
> Let's keep it open until completely done.
As I've said several times now, from my point of view the command is
fine as is. I understand that you want to add unrelated functionality
to this conceptually simple command (and functionality that's already
available much easier via the standard kill/yank commands), but I don't
agree with that.
So I'm re-closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug marked as fixed in version 29.1, send any further explanations to
46621 <at> debbugs.gnu.org and Juri Linkov <juri <at> linkov.net>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Tue, 05 Jul 2022 16:54:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Tue, 05 Jul 2022 20:20:02 GMT)
Full text and
rfc822 format available.
Message #332 received at 46621 <at> debbugs.gnu.org (full text, mbox):
5 juli 2022 kl. 18.52 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:
> As I've said several times now, from my point of view the command is
> fine as is.
We are talking past each other. I'm perfectly happy to keep duplicate-line exactly what you committed; we can make a new command with the new features. I'll open a new bug for it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Wed, 06 Jul 2022 17:44:02 GMT)
Full text and
rfc822 format available.
Message #335 received at 46621 <at> debbugs.gnu.org (full text, mbox):
>> duplicate-line should keep point at the same column.
>
> Ah, yes, that might be nice...
Here is the patch that does this. So if you have
foo 1 bar
and need to get
foo 1 bar
foo 2 bar
foo 3 bar
foo 4 bar
foo 5 bar
it requires typing the minimal number of keys -
move point to the column with 1, and type:
C-u <copy-line> 2 <down> 3 <down> 4 <down> 5 <down>
```
diff --git a/lisp/misc.el b/lisp/misc.el
index 28c5d6e07f..57cf8c59ed 100644
--- a/lisp/misc.el
+++ b/lisp/misc.el
@@ -71,13 +71,15 @@ duplicate-line
(interactive "p")
(unless n
(setq n 1))
- (let ((line (buffer-substring (line-beginning-position) (line-end-position))))
+ (let ((line (buffer-substring (line-beginning-position) (line-end-position)))
+ (column (current-column)))
+ (forward-line 1)
+ (unless (bolp)
+ (insert "\n"))
(save-excursion
- (forward-line 1)
- (unless (bolp)
- (insert "\n"))
(dotimes (_ n)
- (insert line "\n")))))
+ (insert line "\n")))
+ (move-to-column column)))
;; Variation of `zap-to-char'.
```
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 07 Jul 2022 07:59:01 GMT)
Full text and
rfc822 format available.
Message #338 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>>> duplicate-line should keep point at the same column.
>>
>> Ah, yes, that might be nice...
>
> Here is the patch that does this. So if you have
>
> foo 1 bar
>
> and need to get
>
> foo 1 bar
> foo 2 bar
> foo 3 bar
> foo 4 bar
> foo 5 bar
>
> it requires typing the minimal number of keys -
> move point to the column with 1, and type:
>
> C-u <copy-line> 2 <down> 3 <down> 4 <down> 5 <down>
I think I've changed my mind about moving point -- leaving it where it
is makes sense if you've bound `duplicate-line' to a single key, and
then you'd say, for instance, `M-o' `M-o' `M-o' `M-o'. And then you'd
not want point to move, but be left where it is, so you can start
editing by hitting <down>.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 07 Jul 2022 16:50:02 GMT)
Full text and
rfc822 format available.
Message #341 received at 46621 <at> debbugs.gnu.org (full text, mbox):
>> Here is the patch that does this. So if you have
>>
>> foo 1 bar
>>
>> and need to get
>>
>> foo 1 bar
>> foo 2 bar
>> foo 3 bar
>> foo 4 bar
>> foo 5 bar
>>
>> it requires typing the minimal number of keys -
>> move point to the column with 1, and type:
>>
>> C-u <copy-line> 2 <down> 3 <down> 4 <down> 5 <down>
>
> I think I've changed my mind about moving point -- leaving it where it
> is makes sense if you've bound `duplicate-line' to a single key, and
> then you'd say, for instance, `M-o' `M-o' `M-o' `M-o'. And then you'd
> not want point to move, but be left where it is, so you can start
> editing by hitting <down>.
This is optimized for a rare workflow. Why would anyone want
to type a long key sequence `M-o M-o M-o M-o ... <down>' when
it's much easier to type just `M-4 M-o' and immediately start editing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 07 Jul 2022 18:05:02 GMT)
Full text and
rfc822 format available.
Message #344 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> This is optimized for a rare workflow. Why would anyone want
> to type a long key sequence `M-o M-o M-o M-o ... <down>' when
> it's much easier to type just `M-4 M-o' and immediately start editing.
I don't think it's rare -- I think many people rarely say `C-u 3' or
`M-4' and just lean on the keyboard instead.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 07 Jul 2022 18:24:02 GMT)
Full text and
rfc822 format available.
Message #347 received at 46621 <at> debbugs.gnu.org (full text, mbox):
>> This is optimized for a rare workflow. Why would anyone want
>> to type a long key sequence `M-o M-o M-o M-o ... <down>' when
>> it's much easier to type just `M-4 M-o' and immediately start editing.
>
> I don't think it's rare -- I think many people rarely say `C-u 3' or
> `M-4' and just lean on the keyboard instead.
But there is no one-key binding for this command.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 07 Jul 2022 18:25:02 GMT)
Full text and
rfc822 format available.
Message #350 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> But there is no one-key binding for this command.
People may bind it to whatever they choose, like `H-c', if they like the
command.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Fri, 08 Jul 2022 17:20:01 GMT)
Full text and
rfc822 format available.
Message #353 received at 46621 <at> debbugs.gnu.org (full text, mbox):
>> But there is no one-key binding for this command.
>
> People may bind it to whatever they choose, like `H-c', if they like the
> command.
Or copy and edit the whole command in their init files
when they don't like the default implementation 😉.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Sun, 10 Jul 2022 12:58:02 GMT)
Full text and
rfc822 format available.
Message #356 received at 46621 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> Or copy and edit the whole command in their init files
> when they don't like the default implementation 😉.
Sure. But we do add commands without default bindings with the
expectation that if somebody finds it useful, they'll put it somewhere
convenient.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 14 Jul 2022 17:30:02 GMT)
Full text and
rfc822 format available.
Message #359 received at 46621 <at> debbugs.gnu.org (full text, mbox):
>> But there is no one-key binding for this command.
>
> People may bind it to whatever they choose, like `H-c', if they like the
> command.
Why would one want to sacrifice a short keybinding when
it's easier to use a keybinding of any length to copy the
current line, then use C-y C-y C-y ... Also it solves
the main discrepancy of this feature request - whether
to keep point unmoved or to move it on the copied line:
C-y supports the prefix arg `C-u C-y', problem solved.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 14 Jul 2022 17:48:01 GMT)
Full text and
rfc822 format available.
Message #362 received at 46621 <at> debbugs.gnu.org (full text, mbox):
On Jul 14 2022, Juri Linkov wrote:
> Why would one want to sacrifice a short keybinding when
> it's easier to use a keybinding of any length to copy the
> current line, then use C-y C-y C-y ...
C-y requires moving point to bol, which is the main reason I wrote my
own version of duplicate-line.
--
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46621; Package
emacs.
(Thu, 14 Jul 2022 19:31:02 GMT)
Full text and
rfc822 format available.
Message #365 received at 46621 <at> debbugs.gnu.org (full text, mbox):
>> Why would one want to sacrifice a short keybinding when
>> it's easier to use a keybinding of any length to copy the
>> current line, then use C-y C-y C-y ...
>
> C-y requires moving point to bol, which is the main reason I wrote
> my own version of duplicate-line.
And I use my own version of duplicate-line that moves point
to the copied line. This means that adding duplicate-line
to misc.el requested by this feature request was a failure.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 12 Aug 2022 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 333 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.