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

[Mike Frysinger]

On 04 Jan 2016 10:35, Benno Schulenberg wrote:
> 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...

imo we should be trying to converge on readline behavior in all aspects
rather than creating a completely unique/different experience.
-mike

signature.asc
Description: Digital signature