nano-devel
[Top][All Lists]
Advanced

[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: Wed, 18 Jun 2014 06:19:27 -0700

> Well... in the current situation, that cutbuffer_reset() only gets
> called when either the mark is set OR the cutbuffer has already
> been reset.  The latter is unneeded, and for the former... wouldn't
> it be enough to do the call in do_cut_text(), like I proposed earlier?
>
> You see, to me it doesn't feel right that the undo/redo code makes
> a call to cutbuffer_reset(), it is the cutting and copying code that
> should do that.  Please see attached revised version of your patch.

I agree, it doesn't feel right, but all code paths lead through
add_undo().  The conditional statement

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

was already in place and needs to be made.  Having cutbuffer_reset()
in add_undo() guarantees that it will be correctly prepared prior to
making the cut, it sets it for both CUT and CUT_EOL.  The function,
cutbuffer_reset(), is just setting a flag, so not a lot of processing.
It should also be designated inline.

The function do_cut_text(...) is called for all cuts, copying, and
some undo/redo cases.  Putting the call to cutbuffer_reset() in
do_cut_text(...) would not be my choice, that function is complicated
enough.  The place to have the check and call to cutbuffer_reset()
would be in do_cut_text_void(), but this would lead to code similar to
that in do_copy_text().  When calling do_cut_text_void(), we already
have the last line that was cut stored in the undo object, so adding a
static or looking at the undo object would be very redundant, the next
function called will be add_undo().  This would also require a
cutbuffer_reset() in do_cut_till_end().

As it is now, the copy buffer is being wiped out too frequently, it's
unnecessary to clear it when doing an undo/redo.

I would leave cutbuffer_reset() in add_undo().  This allows fiddling
with the other locations of cutbuffer_reset() with a guarantee that it
will be called when absolutely necessary.

--Mark Majeres



reply via email to

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