GNU bug report logs - #64185
proposal for new function: copy-line

Previous Next

Package: emacs;

Reported by: Zachary Kanfer <zkanfer <at> gmail.com>

Date: Tue, 20 Jun 2023 05:09:02 UTC

Severity: wishlist

Full log


View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Mattias EngdegÄrd <mattias.engdegard <at> gmail.com>
Cc: 64185 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, me <at> eshelyaron.com, zkanfer <at> gmail.com
Subject: bug#64185: proposal for new function: copy-line
Date: Sun, 25 Jun 2023 20:24:10 +0300
>> It would be a major undertaking to design
>> a similar option for `duplicate-dwim` for consistency with `duplicate-line`
>> because of more decisions necessary to make: whether to move point
>> to the beginning or the end of the copied regions, whether to select
>> all the copied regions or only one of them, etc.
>
> Actually we are helped by some constraints: duplicate-dwim must keep
> the region active afterwards, so that the user can run the same
> command immediately and get another copy.  This is important for
> usability.

I don't see from where we can get such assumption - e.g. extending the region
to the copied text also makes sense.

> It seems reasonable to assume that a user wants the same behaviour in
> `duplicate-dwim` whether it is lines or columns being duplicated, and
> have a single variable controlling both.  This assumption may be
> wrong: perhaps a user prefers to stay when copying a line, but move
> when copying columns?

When the users will request a setting for columns, then we could
add a new option e.g. `duplicate-dwim-final-column`.

> If we use separate settings they should naturally work the same way,
> or users will wonder who is running the asylum.

It would be crazy to mix apples and oranges.  `duplicate-line-final-line`
should be applied only to `duplicate-line`.  And if the users need to
do the same with regions, then a separate option could be added
e.g. `duplicate-dwim-final-region`.

> A perhaps more intuitive way of describing the behaviour is not where
> to put point afterwards, but whether copies are inserted before or
> after the original.  That will generalise to duplication of regions,
> rectangular or contiguous, a little better.
>
> It's also easy to describe:
>
> (defcustom duplicate-direction 'after
>   "Where to insert the copies made by `duplicate-line' and `duplicate-dwim'.
> Valid values are `after' and `before' (the original text).
>   :group 'editing
>   :type '(choice (const :tag "After original" after)
>                  (const :tag "Before original" before)))
>
> What do you think?  Should we have a single setting for lines and
> regions, or individual settings for lines and regions, or for lines,
> rectangles and contiguous regions?

My first implementation of `duplicate-line` prepended the copied line
before the original line, and that implementation was flawed: it had
no visual feedback when copying the first line at the top of the window.

>> to my surprise the shortdoc of `substring` has no examples
>> of a negative argument.  I don't know whether this omission
>> is intentional to make the string section shorter.
>
> Thank you for noticing this. I doubt it was intentional.
> The examples have now been extended a bit.
> I'm sure we could do better with examples in general if we were to make an effort.

Thanks.

(Not sure why now one example uses boring "abcde"
instead of the overall style with "foo", "bar", "zot").




This bug report was last modified 1 year and 285 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.