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

Previous Next

Full log

Message #89 received at 64185 <at> debbugs.gnu.org (full text, mbox):

From: Zachary Kanfer <zkanfer <at> gmail.com>
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,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#64185: proposal for new function: copy-line
Date: Sat, 24 Jun 2023 23:45:52 -0400

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Previous Next

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