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

[David Ramsey]

Benno Schulenberg:
> For such an editor it is not sensible to hard-wrap lines by default at
> screen width minus eight columns.  For most people scrolling per
> half-screen is disorienting, or the cursor not coming back to the same
> place after a PageDown plus PageUp.  So, in such things nano should
> behave in a sensible way by default, and not stick to whatever Pico
> did.

Agreed.

> Nano doesn't follow Pico's behavior in the Replacing menu, nor its
> Tab-completion-of-filenames behavior, nor its spell-checking behavior,
> nor in a few other things,

True, but it's at least close enough to them that it's recognizable.
Besides, in some cases, Pico's changed its behavior, and nano's behavior
was originally modeled after Pico's *old* behavior.

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

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.

> But the basic keybindings (^X for exit, ^W for search, etcetera) are
> not going to change, nor the peculiar manner of cutting (per full line
> and cumulative).  Regular users of nano are too used to those.

Agreed.