nano-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] [PATCH 1/2 V3] cutting: when ^K does not actually cut a


From: David Ramsey
Subject: Re: [Nano-devel] [PATCH 1/2 V3] cutting: when ^K does not actually cut anything, do not add an undo item
Date: Tue, 29 Jan 2019 01:37:27 -0600

Benno Schulenberg:
> An example?

Several.  Marked justify that affects only the marked text instead of
shifting the mark (which is the entire point of my patch set in the bug
tracker, which you should remember).  Backward searching available via
^W^P when it wasn't available in Pico before.  Word movement via
Ctrl-Left and Ctrl-Right (and even Esc-Esc-Left and Esc-Esc-Right, which
nano doesn't do) when it wasn't available in Pico before.

> But why would the user *want* to cut an empty region?  It serves no
> purpose.

It's not about wanting to cut an empty region.  It's about doing the
lest destructive thing if an empty region is highlighted.

> The two things are vastly different.  First, the M-T is typed by
> accident, and the ^K is typed on purpose.

The mark before the ^K is typed (or mouse-clicked) by accident in this
case.

> Second, most users will never use M-T (and may not even know of its
> existence),

It's in the help with everything else, so they should know if they read
the help at some point.  And, as I've said several times, you don't know
what most people do or do not use.

> Third, it seems unlikely to me that an empty region comes about by
> accident:

There's the case of mouse support.  If mouse support is on, and I have
to click inside the terminal that nano's running in in order to focus
the window, and I happen to hit near where the cursor is, I end up
toggling the mark.  And if I'm multi-tasking, I can lose track of
whether the mark is off or on, since the empty region makes it
invisible.

> and when just one character is involved neither, because on my
> keyboards the <Left> and <Right> keys are not next to each other;

Not all keyboards are laid out like yours.

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

If the mark is empty, there's no highlight to give visual feedback.

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

That's only true for your particular use cases.

> But never mind, I will let it be for now.

Thank you.

> But... nano has seen several small changes in behavior over the past
> few years, have you ever heard someone complain?

Actually, we both have (which you should also remember).  But that's
really a separate issue from this one.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]