[Top][All Lists]

[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: Benno Schulenberg
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 19:34:55 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

Op 29-01-19 om 08:37 schreef David Ramsey:
> Benno Schulenberg:
>> An example?
> Several.  Marked justify that affects only the marked text instead of
> shifting the mark [...].  Backward searching available via
> ^W^P when it wasn't available in Pico before.  Word movement via
> Ctrl-Left and Ctrl-Right [...] when it wasn't available in Pico before.

That's not what I meant.  What I asked for is behaviors of nano where
nano does what Pico did before and Pico has changed its behavior since
then.  I didn't ask about new functionality that Pico acquired.

Anyway, the marked justify, we only recently discovered that Pico can
do that.  It is a nice thing to have, but not a high priority for a
general text editor.  The backward searching nano implemented in its
own way, and we have stuck to that when Pico implemented a different
way -- that is: nano stuck to its own way instead of to Pico's way.
(And recently we added a better way, with ^Q and M-Q.)  And the
Ctrl+Left/Right was implemented in nano not because we wanted to
follow Pico but because I have been asking for it since 2006.

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

But when the region is empty, there *is* no highlight, nothing is

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

If really the mark was switched on by accident, then when the user
types ^K, he or she *expects* ^K to cut the current line.  I want ^K
to do what the user most likely expects, not the least "destructive"
thing -- there is M-U, after all; I use it every few minutes.

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

It is well know that most people never read manuals or help texts.
They type, and see what happens.

> And, as I've said several times, you don't know
> what most people do or do not use.

I don't *know*, true, but I'm pretty sure that I am a rather average
nano user.

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

Precisely.  When people check for the highlight and they don't see any,
most will conclude that they mistyped something and the mark is off.
So when they then do type ^K, they expect it to cut the current line.
When it doesn't... bweh.

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

WTF?  Stop making me guess and speak clear language.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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