bug#49194: kill-whole-line 'plus-newline-even-if-none-in-reality

bug#49194: kill-whole-line 'plus-newline-even-if-none-in-reality

[積丹尼 Dan Jacobson]

The kill-whole-line variable is great, but not great enough.

(info "(emacs) Killing by Lines") says:
     If the variable ‘kill-whole-line’ is non-‘nil’, ‘C-k’ at the very
  beginning of a line kills the entire line including the following
  newline.  This variable is normally ‘nil’.

So setting it to non-nil allows us to get newlines, 99% of the time.

I hereby propose an additional value, call it one of:

   'always
   'no-matter-what
   'plus-newline-even-at-eof
   'plus-newline-even-if-none-in-reality

> See (info "(emacs) Customize Save") for require-final-newline. Bye.

Wait! Who says I even want the file to end in a newline? I just want
kill-whole-line to have a setting to consistently get a newline at the
end, and not 99% of the time.

> Then add a newline there yourself and remove it when you are finished. Bye.

Wait! The file might even be a readonly file owned by someone else. I
can't just "add one there myself."

> Well then copy the file first. Bye.

Seems like overkill, just to kill (copy) one line.

Anyway 'plus-newline-even-if-none-in-reality etc., being non-nil, would
also be 99% backwards compatible too!

bug#49194: kill-whole-line 'plus-newline-even-if-none-in-reality

[Lars Ingebrigtsen]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> I hereby propose an additional value, call it one of:
>
>    'always
>    'no-matter-what
>    'plus-newline-even-at-eof
>    'plus-newline-even-if-none-in-reality
>
>> See (info "(emacs) Customize Save") for require-final-newline. Bye.
>
> Wait! Who says I even want the file to end in a newline? I just want
> kill-whole-line to have a setting to consistently get a newline at the
> end, and not 99% of the time.
>
>> Then add a newline there yourself and remove it when you are finished. Bye.
>
> Wait! The file might even be a readonly file owned by someone else. I
> can't just "add one there myself."
>
>> Well then copy the file first. Bye.
>
> Seems like overkill, just to kill (copy) one line.
>
> Anyway 'plus-newline-even-if-none-in-reality etc., being non-nil, would
> also be 99% backwards compatible too!

I'm not quite sure what this essay is trying to express -- are you
asking for a new setting for `kill-whole-line' that deletes the preceding
newline if you call `C-k' at the start of the final line in a buffer,
and that final line doesn't have a newline at the end?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49194: kill-whole-line 'plus-newline-even-if-none-in-reality

[積丹尼 Dan Jacobson]

>>>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:

LI> I'm not quite sure what this essay is trying to express -- are you
LI> asking for a new setting for `kill-whole-line' that deletes the preceding
LI> newline if you call `C-k' at the start of the final line in a buffer,
LI> and that final line doesn't have a newline at the end?

No. I'm just saying that a bonus newline should be added to what gets
copied (so later, upon C-y, it is present.)

bug#49194: kill-whole-line 'plus-newline-even-if-none-in-reality

[Lars Ingebrigtsen]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> No. I'm just saying that a bonus newline should be added to what gets
> copied (so later, upon C-y, it is present.)

I think that sounds like really surprising behaviour, but I guess if
it's hidden behind a new `kill-whole-line' value, I guess I don't have
any objections to adding it.  Any other opinions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49194: kill-whole-line 'plus-newline-even-if-none-in-reality

[積丹尼 Dan Jacobson]

>>>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:

LI> I think that sounds like really surprising behaviour, but I guess if
                                                        ^(more surprising
                                                        is the lack of
                                                        newlines on
                                                        certain C-y's
                                                        later.)

bug#49194: kill-whole-line 'plus-newline-even-if-none-in-reality

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 24 Jun 2021 20:26:23 +0200
> Cc: 49194@debbugs.gnu.org
> 
> 積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:
> 
> > No. I'm just saying that a bonus newline should be added to what gets
> > copied (so later, upon C-y, it is present.)
> 
> I think that sounds like really surprising behaviour, but I guess if
> it's hidden behind a new `kill-whole-line' value, I guess I don't have
> any objections to adding it.  Any other opinions?

AFAIU, what the OP wants already happens: the newline is saved in
kill-ring together with the line, and is yanked back with C-y.  So I
don't think I understand the request.

bug#49194: kill-whole-line 'plus-newline-even-if-none-in-reality

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> AFAIU, what the OP wants already happens: the newline is saved in
> kill-ring together with the line, and is yanked back with C-y.  So I
> don't think I understand the request.

He wants to kill the final line in a buffer (that might not have a
newline character at the end), but end up with a string in the kill ring
that does have a newline at the end.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49194: kill-whole-line 'plus-newline-even-if-none-in-reality

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: jidanni@jidanni.org,  49194@debbugs.gnu.org
> Date: Thu, 24 Jun 2021 20:46:37 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > AFAIU, what the OP wants already happens: the newline is saved in
> > kill-ring together with the line, and is yanked back with C-y.  So I
> > don't think I understand the request.
> 
> He wants to kill the final line in a buffer (that might not have a
> newline character at the end), but end up with a string in the kill ring
> that does have a newline at the end.

That makes no sense to me: the command kills a line of buffer text, it
doesn't (and shouldn't) invent characters out of thin air.  When there
_is_ a newline at EOL, setting kill-whole-line will cause C-k to kill
that newline as well; but if there's no newline there, why should this
particular command with that option invent such a newline and save it
in kill-ring?

bug#49194: kill-whole-line 'plus-newline-even-if-none-in-reality

[積丹尼 Dan Jacobson]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

EZ> That makes no sense to me: the command kills a line of buffer text, it
EZ> doesn't (and shouldn't) invent characters out of thin air.  When there
EZ> _is_ a newline at EOL, setting kill-whole-line will cause C-k to kill
EZ> that newline as well; but if there's no newline there, why should this
EZ> particular command with that option invent such a newline and save it
EZ> in kill-ring?

1. There may not be a newline yet, but there will be upon sending the
message, or saving the file, depending on other settings.

2. That allows consistent yanking later. C-k ... C-y now will always
have a newline. Else even though C-k appears to behave the same at the
end of file, C-y depends different later.

Anyway, just try making a bunch of lines like this:
                                   ^^^^^^^^^^^^^^^
                                   ^^^^^^^^^^^^^^^
                                   ^^^^^^^^^^^^^^^
at the end of your reply, without extra fuss when copying the first!

bug#49194: kill-whole-line 'plus-newline-even-if-none-in-reality

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  49194@debbugs.gnu.org
> Date: Fri, 25 Jun 2021 04:20:50 +0800
> 
> >>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> EZ> That makes no sense to me: the command kills a line of buffer text, it
> EZ> doesn't (and shouldn't) invent characters out of thin air.  When there
> EZ> _is_ a newline at EOL, setting kill-whole-line will cause C-k to kill
> EZ> that newline as well; but if there's no newline there, why should this
> EZ> particular command with that option invent such a newline and save it
> EZ> in kill-ring?
> 
> 1. There may not be a newline yet, but there will be upon sending the
> message, or saving the file, depending on other settings.
> 
> 2. That allows consistent yanking later. C-k ... C-y now will always
> have a newline. Else even though C-k appears to behave the same at the
> end of file, C-y depends different later.
> 
> Anyway, just try making a bunch of lines like this:
>                                    ^^^^^^^^^^^^^^^
>                                    ^^^^^^^^^^^^^^^
>                                    ^^^^^^^^^^^^^^^
> at the end of your reply, without extra fuss when copying the first!

If this is about your personal needs, why not make a keyboard macro to
achieve what you want, and use it thereafter?  IMO, we shouldn't add
to Emacs stuff that is needed by a single user (or a small number of
users) because of their peculiar workflows, and which makes little
sense with other workflows.  Inventing characters at kill time sounds
very strange an unintuitive behavior, so adding it to Emacs, even as
an option, would be a mistake, IMO.

bug#49194: kill-whole-line 'plus-newline-even-if-none-in-reality

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> If this is about your personal needs, why not make a keyboard macro to
> achieve what you want, and use it thereafter?  IMO, we shouldn't add
> to Emacs stuff that is needed by a single user (or a small number of
> users) because of their peculiar workflows, and which makes little
> sense with other workflows.  Inventing characters at kill time sounds
> very strange an unintuitive behavior, so adding it to Emacs, even as
> an option, would be a mistake, IMO.

It's not something I'd use myself, but it makes some kind of vague sense
that I could see being generally useful.  That is -- "it'd be nice if
`C-k' always put an entire, full line into the kill ring".

But I agree that it's somewhat obscure functionality, so unless there's
a greater clamouring for this, we probably shouldn't add it, and I'm
closing this bug report.

(If several other people pipe up saying "that's what I've wanted all my
life!" then we could reconsider.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49194: kill-whole-line 'plus-newline-even-if-none-in-reality

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 積丹尼 Dan Jacobson <jidanni@jidanni.org>,
>   49194@debbugs.gnu.org
> Date: Fri, 25 Jun 2021 16:02:36 +0200
> 
> (If several other people pipe up saying "that's what I've wanted all my
> life!" then we could reconsider.)

Right.

bug#49194: kill-whole-line 'plus-newline-even-if-none-in-reality

[積丹尼 Dan Jacobson]

Just like some people see the need to always append a "\n" to the end of
a file, some people also see the need to always append a "\n" to the
end of what C-k kills.