Re: [Nano-devel] interrupting contiguous cuts (or not) with horizontal movement

[Mark Majeres]

On 6/14/14, Benno Schulenberg <address@hidden> wrote:
>
> Hi Mark,
>
> On Sat, Jun 14, 2014, at 18:03, Mark Majeres wrote:
>> I think all the problems you mention about the ^K's and the segfault
>> can be resolved by leaving the call to cutbuffer_reset() in text.c per
>> my patch, and instead removing the cutbuffer_reset() from nano.c.
>> Have you tried this?
>
> Hmm... No, I hadn't tried that.  Have done that now.
>
> Wow.  It does work.  Behaviour appears to be identical as
> with my own little patch, but my patch I understand, and
> yours I don't: it even gets rid of this whole 'preserve'
> checking, which is beautiful, but puzzling.
>
> However... with your patch nano is now very "conservative".
> Before the patch, any cursor movement would break a series
> of ^Ks, but now only vertical movement breaks a series.
> One can even search for a word in the current line and
> still subsequent ^Ks will be glued to the previous ones!
>
> This is a rather big change in behaviour.  Personally I have
> gotten used to doing an <Up><Down> to break a series of
> linecuts, but maybe some people have gotten into the habit
> of doing <Right><Left> -- they would be sourly annoyed if
> that no longer blows away the previously cut stuff.
>
> How to solve that?
>
> Benno

Well, I noticed a problem in my version of the solution.  If you copy
two lines, ^C ^C, then move down two lines<dn><dn>, then copy line
again, ^C.  All three lines end up in the cut buffer.  The problem
occurs because add_undo() isn't called for copy().

This is the conditional in add_undo() that determines if
cutbuffer_reset() is called:

if (u && u->mark_begin_lineno == fs->current->lineno &&
        ((current_action == CUT && u->type == CUT && !u->mark_set)

So, I checked your version of the solution.  The problem I mentioned
with copy lines does not exist, however I noticed this problem.  If
you cut two lines, ^K ^K, move down a line and back up without doing
anything else,<dn> <up>,  cut another couple lines, ^K ^K, then undo,
^Z ^Z, the second undo is missing

I can see the problem if someone is used to clearing the cut buffer
with a left/right.  I don't know what the solution would be to keep
this and still satisfy the other requirements, without seemingly
complex conditionals scattered around. A solution for the user to
clear the cutbuffer in this situation would be to mark the line(s) and
then cut.

Mark