bug#46621: Copy line

[Eli Zaretskii <eliz@gnu.org>]

> From: Juri Linkov <juri@linkov.net>
> Date: Mon, 22 Feb 2021 11:07:58 +0200
> Cc: 46621@debbugs.gnu.org, larsi@gnus.org, mardani29@yahoo.es
> 
> >   > It's not realistic to change the meaning of the numeric arg to C-y.
> >   > People already use the current meaning for decades.
> >
> > We could inquire of the users to see what they think about the issue.
> 
> Every once in a while the lack of such fundamental command sparks very
> long discussions how to reinvent the wheel.  Some recent examples:

Thanks for the links.

However, I don't think they add anything substantial to this
discussion.  For starters, many posters there just wanted to know how
many keystrokes it takes in Emacs to copy a line, and some even said
they wanted to compare the result with Vim.  They don't necessarily
ask for a command or a single short key sequence to do that, at least
not in every post.

More importantly, I see no description of the situations where such a
copy is needed, so it is hard to analyze reason about the necessity.
For example, perhaps some of the posters wanted this because they are
unaware of some existing Emacs features which can do the job
efficiently enough.

This is why I asked here to describe the use cases, i.e. the
situations where such a command would be needed.  I didn't get any
answers to that, AFAIR.  Just one person posted his experiences.

Without knowing what situations necessitate such a command, I don't
see how we will be able to reason whether the needs justify adding the
command.  And reason we must, because we cannot possibly implement
feature after feature just because someone asks about it on
stackexchange.

> The proposed tiny 8-line patch was intended to help people avoid
> wasting their time on such trivial things.

Yes, this command is relatively small.  But we must have some criteria
for adding new commands and features, because otherwise we will add 8
lines, then another 10 lines, then 5 more, etc. etc.  These things add
up, and that's even before you consider the supporting docs and other
consequences.

Bottom line, if we want to consider this command, we should somehow
come up with the relevant use cases, and then weigh them against the
added complexity and maintenance costs.  I therefore urge people who
think they know these details to please speak up and contribute to
this discussion.