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

[Zachary Kanfer]

>  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?