[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: 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, 1 Jan 2019 16:25:12 -0600

Benno Schulenberg:
> I don't think it's simpler, nor clearer.  But it is longer, and would
> necessitate a linewrap for the second condition.  also, I like the
> rhythm of NULL, \0, NULL.

You're testing for current's being on the bottom line of the file;
that's what filebot is for.  Also, "current == filebot" is one
comparison, while "current->next == NULL" is a dereference followed by a
comparison; in terms of instructions, the former *is* simpler.

> Well, I like to see contrast, in variable names, and in messages.
> When I would "Nothing to paste", I would think "Nothing to paste...?
> Ah, the cutbuffer is empty. Say that then."  Also, it introduces the
> word cutbuffer, the concept, which the user could then search for in
> the help text or the man page.

If there's too much contrast, it can make things more difficult.  Both
cutting and pasting affect the cutbuffer, but if only one of the
messages regarding them references the cutbuffer, it will make it that
much harder for a newbie to discover what the "cutbuffer" refers to.

> And I chose "Nothing was cut" instead of "Nothing to cut" because when
> doing ^6 followed by ^K (or followed by <Bsp> or <Del> when using
> --zap), "Nothing to cut" looks weird.  My reaction would be: "What do
> you mean, nothing to cut? Type it again and it *does* cut."


> But maybe, when the mark covers zero characters, and a cutting key is
> pressed, we should treat it as if the mark is off?

If the user is on the line

this is a test

and the cursor is on, say, the space after "this", and the mark is on
but covers no characters, and the user presses ^K, acting as though the
mark is off would delete the entire line.

It's possible to forget that the mark is on if it covers no characters,
since there's no visual indicator for it then, and this behavior would
be unexpected in that case (especially since Pico doesn't act that way
either).  So this sounds like a bad idea to me.  Indicating that nothing
gets cut in that case is much better.

reply via email to

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