[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