Re: [Nano-devel] [PATCH 1/2 V3] cutting: when ^K does not actually cut anything, do not add an undo item

[Benno Schulenberg]

Op 09-01-19 om 21:47 schreef David Ramsey:
> Besides, in some cases, Pico's changed its behavior,

An example?

>> so why should it copy the marking behavior exactly?  Why "cut" an
>> invisible, empty region?  It doesn't actually cut anything: it doesn't
>> make sense.
> 
> If the mark is on, the text covered by the mark is cut.  If the mark is
> on but doesn't cover any text, no text is cut *because* no text is
> covered by the mark.  It makes perfect sense to me (and at least one
> non-programmer I ran it by).

But why would the user *want* to cut an empty region?  It serves no purpose.
The only reason I can come up with is that the user wants to clear the
cutbuffer (maybe because they often type ^U by accident because they are
used to the readline keybindings).  But with the recent changes that prevent
adding an undo item for an "empty cut", the cutbuffer is no longer cleared
either, so that one possible use case is gone.

> Also, considering your recent complaints about accidentally hitting the
> cut-to-eof key so often before undo was working, I thought you'd be more
> concerned about overly destructive behavior regarding text.

The two things are vastly different.  First, the M-T is typed by
accident, and the ^K is typed on purpose.  Second, most users will
never use M-T (and may not even know of its existence), so when they
hit it by accident, their most likely reaction will be: "What the
heck happened!?", whereas most users will be fully familiar with ^K
and its normal behavior: cutting the entire current line, so when ^K
does this, they will not be very surprised, and they know perfectly
well how to "undo" it: ^U.  Third, it seems unlikely to me that an
empty region comes about by accident: when multiple lines or
characters are involved, I cannot see how the cursor could
accidentally get back to where the mark is; and when just one
character is involved neither, because on my keyboards the <Left>
and <Right> keys are not next to each other; and when just one line
is involved, it is somewhat unlikely that start and end point of the
selection are right above one another so that an accidental press of
<Up> after <Down> (or the other way around) would result in an empty
region.  And fourth, when making a selection, I would think that
people check for the visual feedback of the highlighted text before
they actually press ^K.  So, all in all, I think that the accidental
M-T and the accidental empty region followed by a too-fast ^K are
three or four orders of magnitude apart, in terms of impact,
probability, and mechanics all taken together.

But never mind, I will let it be for now.  Maybe there are people
who, when they have switched on the mark with ^6 and then change
their mind, do not use ^6 to switch it off again but just press ^K
to do that.  If we change the behavior, those people would be sourly
surprised.  But... nano has seen several small changes in behavior
over the past few years, have you ever heard someone complain?
People may be surprised, but they apparently adapt to the new
mechanics without protest.

Benno

signature.asc
Description: OpenPGP digital signature