[Top][All Lists]

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

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

From: Benno Schulenberg
Subject: Re: [Nano-devel] the difficulties of behaving similar
Date: Wed, 18 Jun 2014 21:18:18 +0200

Hello Mark,

On Wed, Jun 18, 2014, at 15:19, Mark Majeres wrote:
> 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.

Hm?  Your patch added the !is_cutbuffer_reset() -- which I've renamed
to keeping_cutbuffer() to avoid confusion with cutbuffer_reset().

By the way, this 'u->mark_begin_lineno == fs->current->lineno',
does it not only apply to the case of 'current_action == ADD'?
For the 'current_action == CUT' condition the mark must not be set,
so then 'u->mark_begin_lineno' should be irrelevant, no?

And further, is it possible for 'u' to be NULL there?  And if not,
wouldn't an assert make more sense?

> 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,

Okay, I have applied your patch as it was, with just the rename and
the shuffling of the conditions (to make clearer what the patch adds),
plus some comment changes.  Thanks!

However, in a later patch I will probably move the cutbuffer_reset()
call to places where they make more sense to me.

> This would also require a
> cutbuffer_reset() in do_cut_till_end().

Ah, yeah -- I knew I would be overlooking something.


-- - Faster than the air-speed velocity of an
                          unladen european swallow

reply via email to

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