bug#64185: proposal for new function: copy-line

[Zachary Kanfer <zkanfer@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]

>  And I agree that allowing any integer as value isn't necessary the best
choice here. It's a false flexibility; nobody will ever set it to something
other than 0, 1 or -1. Symbols would probably be better, for several
reasons.

I agree. The reasons I can think of are as follows:

1. These values will be read far more often than they are written. A symbol
like 'last is somewhat self-documenting. On the other hand, what is 1? Is
it the old line, because it's highest up on the screen? Is it the last new
line, because the last new line has the greatest point, and 1 is the
greatest of the options? (In the current implementation, it's the first new
line. Did you know that until I mentioned it?) The values have to be
recalled each time they are used.
2. These settings aren't really integers. We won't want to add, multiply,
subtract or divide them.
3. Using integers leads to more complicated code. The current patch has a
line (unless (< duplicate-line-final-position 0) ...). I believe this would
be easier to read as (unless (equal duplicate-line-final-position 'last)
...).

On Fri, Jun 23, 2023 at 5:08 AM Mattias Engdegård <
mattias.engdegard@gmail.com> wrote:

> >  'duplicate-dwim' duplicates the region if it is active.  If not, it
> >  works like 'duplicate-line'.  An active rectangular region is
> > -duplicated on its right-hand side.
> > +duplicated on its right-hand side.  The new user option
> > +'duplicate-line-final-position' specifies where to move point
> > +after duplicating the line.
>
> This makes it unclear to what extent the variable affects
> `duplicate-dwim`. (For some reason it only does so when the region is
> inactive, which doesn't seem right.)
>
> And I agree that allowing any integer as value isn't necessary the best
> choice here. It's a false flexibility; nobody will ever set it to something
> other than 0, 1 or -1. Symbols would probably be better, for several
> reasons.
>
> Finally, it's a bit surprising that this is even discussed for inclusion
> in Emacs 29 at this stage, given the raw state of the design. What about we
> do a proper job on master instead, instead of rushing a half-baked new
> feature into a branch that is already deep into pre-release?
>
>

[-- Attachment #2: Type: text/html, Size: 2711 bytes --]