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

[Mark Majeres]

Benno,

> Aah.  I had an inkling of that, but this "mark" was throwing me off.
> It should be renamed then, no?  Any suggestions?
I haven't looked to see if this makes sense for all of the current
assignments, but maybe something like this:
    lineno --> end_lineno
    begin_x --> end_x
    mark_begin_lineno   --> begin_lineno
    mark_begin_x --> begin_x

Also note, the mark_begin* members are always the top/left of selected text.
When the text has been marked from bottom-->top or right-->left the
flag 'UNcut_marked_backwards' is set to indicate the situation.

> Hmmm...  When the mark is not set, and some command key did not
> reset the cutbuffer when it should have, then the add_undo() item
> for CUT will not be reached because keeping_cutbuffer() wil be true.
> No?  Like I said before, the call to cutbuffer_reset() in CUT ever
> only has an effect when the mark is set or the action is CUT_EOF.

The conditional also requires that the current line is the next contiguous line:
   u->mark_begin_lineno == fs->current->lineno

Ths check needs to be done anyway so a new undo object is not created
and the current cutbuffer is added to the existing undo object in
update_undo.  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.

BTW, the entire mechanism for copy/cut/paste is not very efficient
IMO.  For example, when copying, the text is cut, then pasted back in.
Why not just paste it to the cutbuffer instead, without cutting it
from the document?  I always thought this was strange, maybe I
overlooked something?  No really a big deal though, it functions fine.

--Mark Majeres