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

[Juri Linkov]

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