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

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Zachary Kanfer <zkanfer <at> gmail.com>
Cc: 64185 <at> debbugs.gnu.org, Mattias Engdegård <mattias.engdegard <at> gmail.com>, me <at> eshelyaron.com, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#64185: proposal for new function: copy-line
Date: Sun, 25 Jun 2023 20:19:20 +0300

> 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) .
> ..).

This might surprise you, but code would be more complicated with symbols.
Instead of

  (unless (eq duplicate-line-final-position 0)
    (forward-line duplicate-line-final-position)

it will be

  (unless (eq duplicate-line-final-position 'old-original-line)
    (when (eq duplicate-line-final-position 'first-copied-duplicate-line)
      (forward-line 1))
    (when (eq duplicate-line-final-position 'last-copied-duplicate-line)
      (forward-line -1))

Previous Next

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