nano-devel
[Top][All Lists]
Advanced

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

Re: [Nano-devel] RFC: should cutword overwrite the cutbuffer?


From: Benno Schulenberg
Subject: Re: [Nano-devel] RFC: should cutword overwrite the cutbuffer?
Date: Mon, 04 Jan 2016 10:35:15 +0100

On Sun, Jan 3, 2016, at 23:55, Mike Frysinger wrote:
> On 03 Jan 2016 21:57, Benno Schulenberg wrote:
> > To see what I mean, put for example 'bind ^D cutwordleft main'
> > into your .nanorc, then run 'src/nano +3 NEWS', and type
> > ^K ^D ^D ^D ^D, then type ^U.  Instead of the deleted line
> > getting pasted back, only the last deleted word is: "as".
> 
> i think it's buggy that the cuts do not accumulate.  otherwise,
> why does ^K ^K ^K ^U put back three lines ?

Hm, okay, that is another option: let cutwords accumulate.

But... this compicates things: should cutwordlefts and
cutwordrights accumulate together, or separately?  In
general they cannot accumulate with ^K, but they could
when option 'cuttoend' is set.  Should they then?

> yes, cut functions should operate on the buffer.  what you're describing
> is a "kill" or "delete" function, not a "cut" function.

Well... that is a matter of naming.  The readline function is
called 'kill-word', but the result can be yanked back anyway.

If the word 'cut' is the problem, I can rename it to 'kill'.

> it would be nice if we had full access to readline bindings using the
> same names (`man 3 readline`).  then people could bind to the exact ops
> they want like kill-word instead of cutwordright.

Yes, that would be somewhat nice.  But then we would have the
problem that the functions are not entirely the same: readline's
forward-word goes to the first whitespace after a word, nano's
nextword goes to the first character of the subsequent word.
If those functions would be named the same...

Benno

-- 
http://www.fastmail.com - Or how I learned to stop worrying and
                          love email again




reply via email to

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