[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
- Re: [Nano-devel] interrupting contiguous cuts (or not) with horizontal movement, (continued)
- Re: [Nano-devel] interrupting contiguous cuts (or not) with horizontal movement, Mark Majeres, 2014/06/15
- Re: [Nano-devel] interrupting contiguous cuts (or not) with horizontal movement, Benno Schulenberg, 2014/06/15
- Re: [Nano-devel] interrupting contiguous cuts (or not) with horizontal movement, Mark Majeres, 2014/06/15
- Re: [Nano-devel] interrupting contiguous cuts (or not) with horizontal movement, Benno Schulenberg, 2014/06/15
- [Nano-devel] the difficulties of behaving similar, Benno Schulenberg, 2014/06/17
- Re: [Nano-devel] the difficulties of behaving similar, Mark Majeres, 2014/06/18
- Re: [Nano-devel] the difficulties of behaving similar, Benno Schulenberg, 2014/06/18
- Re: [Nano-devel] the difficulties of behaving similar,
Mark Majeres <=
- Re: [Nano-devel] the difficulties of behaving similar, Benno Schulenberg, 2014/06/18
- Re: [Nano-devel] the difficulties of behaving similar, Mark Majeres, 2014/06/18
- Re: [Nano-devel] the difficulties of behaving similar, Benno Schulenberg, 2014/06/19
- Re: [Nano-devel] the difficulties of behaving similar, Mark Majeres, 2014/06/19
- Re: [Nano-devel] the difficulties of behaving similar, Benno Schulenberg, 2014/06/21
- Re: [Nano-devel] the difficulties of behaving similar, Mark Majeres, 2014/06/21
- Re: [Nano-devel] the difficulties of behaving similar, Benno Schulenberg, 2014/06/21
- Re: [Nano-devel] the difficulties of behaving similar, Mark Majeres, 2014/06/21
- Re: [Nano-devel] the difficulties of behaving similar, Benno Schulenberg, 2014/06/22
- Re: [Nano-devel] the difficulties of behaving similar, Mark Majeres, 2014/06/22