[Top][All Lists]

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

Re: [Nano-devel] the difficulties of behaving similar

From: Mark Majeres
Subject: Re: [Nano-devel] the difficulties of behaving similar
Date: Sat, 21 Jun 2014 08:30:25 -0700


>> The conditional also requires that the current line is the next contiguous
>> line:
>>    u->mark_begin_lineno == fs->current->lineno
> Contiguous?  I understand this to mean that the line where the
> cutting started is still the current line -- and this will automatically
> be the case when using ^K.  And when the mark is set, any cursor
> movement that moved off this line will have reset the cutbuffer
> already.

When the comparison is made, u is pointing to the last undo object
that was created.  This would be the undo from a prior ^K, not the
just issued ^K.  So if line5 is cut in the first ^K,
u->mark_begin_lineno=line5 and line6 becomes line5, the next ^K  calls
add_undo and checks if the current line is line5.

>> Right now, the call(s) to cutbuffer_reset() in nano.c do
>> make the call in add_undo redundant for *most* cases.  If you remove
>> those calls, then it will matter for *all* cases.
> Hmm.  Strange, I cannot get my head around this, but it works
> -- except that any horizontal movement within the current line
> will not reset the cutbuffer.  Maybe the x coordinate needs to be
> added to the above condition as well?

Yeah, that may be a good check to add.  Another thought is to have a
shortcut that specifically resets the cutbuffer, instead of the adhoc
method of moving the cursor around.


reply via email to

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