Re: Various simple.el patches

[Luc Teirlinck <teirllm@dms.auburn.edu>]

Stefan Monnier wrote:

   > The following version of kill-whole-line should work OK with the
   > kill-ring, including read-only buffers, and with invisible text.

   I'd really like to see it implemented as a wrapper around kill-line.
   After all, it seems that the bug you're fixing also plagues kill-line
   when `kill-whole-line' is set, so it should be fixed there too.

To make sure we understand each other: we are talking about the bug
with the kill ring handling.  I was unable to produce such bugs with
kill-line while kill-whole-line is set to t.  Can you produce such
bugs?  It is easy to actually produce such bugs while trying to
implement one's own versions of the function kill-whole-line using the
variable kill-whole-line.  But I believe that the point of the
variable is that you can do C-a C-k C-k... instead of C-a and then
double the amount of C-k's. It is clear to the user that the C-a is
going to "break" the kill-ring and start a new entry.

   I'd really like to see it implemented as a wrapper around kill-line.

This is a matter of taste.  Kai originally implemented it as such, but
also seemed to suggest that he thought it might be better to use only
kill-region.  My fix for the kill-ring handling indeed would work just
as fine for a kill-line based function.  My version of kill-whole-line
allows for a M--1 S-<backspace> C-x z z z... functionality which
sometimes can be useful.  I guess that, one way or the other, it
should be possible to get the same effect with a kill-line based
function.  

But kill-line is very much a user level function with plenty of
special features.  Use of kill-line would make `kill-whole-line'
vulnerable to any change or addition to the user level features of
kill-line.  I prefer using the more primitive kill-region.

Sincerely,

Luc.