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

[Mark Majeres]

> It is good, but... there is still one difference between cutting
> and copying: any toggle will not break a series of ^K (as was
> recently decided and implemented), but it will break a series
> of M-6 (your ^C).  And I totally don't understand why...

I didn't find problems in either case.  Toggling the cursor pos w/ M-C
doesn't break the series for ^K or ^C.  Also, if preserve is set to
FALSE when a toggle is detected, then M-C breaks the series for both
^K and ^C.

> Or... maybe this cutbuffer_reset() in add_undo() shouldn't
> be there?  If I remove it, I can't find anything wrong any
> more.  Do you agree that that is the right thing?
>

The cutbuffer_reset() in add_undo() is the most important one, it
needs to stay there.

Try this, mark a word and cut it, ^K, then without moving the cursor
cut the line, ^K.
The cutbuffer will have both cuts in it.  So a paste will not work,
neither will the undo's.

The function add_undo is called *before* the text is cut or pasted.
add_undo() just creates a new undo object and prepares it.  After the
operation has completed, update_undo() is called and the undo object
is filled with the cutbuffer contents.

The calls (in pseudo-code) for cut and copy/paste look like this:

add_undo(CUT)
cut()
update_undo(CUT)

copy()
add_undo(PASTE)
paste()
update_undo(PASTE)

The call to add_undo(CUT) will return early if the cut_buffer is to be
preserved, else a new undo is added, and a new series is started. When
a new series starts, the cutbuffer needs to be empty, thus the
importance of having cutbuffer_reset() in add_undo().  The call is
often redundant, as the buffer may have been reset by other keystrokes
already, but it *always* needs to be done in preparation for a new
series of cuts.

The copy operation does not require an undo, so a check similar to the
one performed in add_undo(CUT) is performed inside the do_copy_text()
function.

--Mark Majeres