Re: [Nano-devel] Updated FIX for undo/redo (SPLIT removal)

[Benno Schulenberg]

On Tue, May 27, 2014, at 6:14, Mark Majeres wrote:
> On 5/26/14, Benno Schulenberg <address@hidden> wrote:
> > But... doesn't the do_wrap(openfile->current, FALSE) call in
> > nano.c create undo structures with SPLIT?  And do_justify()
> > in text.c?
> 
> Ha! Your right!  I was duked by the double negative.  The lines "if
> (!undoing)" tripped me up.  There is a lot of that style in nano.  I
> had a hell of time with 'undo uncut' too. :)

Yeah.  Sometimes I have to pause for ten or twenty seconds and
repeat and repeat and repeat a condition to figure out what it
is actually doing.  :|

> I don't understand why a user would unset nowrap though, that's some
> strange functionality.

Ah, pico compatibility!  Pico is meant for composing emails, and there
users want the text to autowrap, and when they later add or delete
some words, they want to be able to hit ^J to rejustify the paragraph.
So, yes, the default (having nowrap unset) has to stay.

> If nowrap does need to stay, then I propose
> using the function do_enter() to accomplish the wrap and throw out
> dowrap() along with my patch.

Whatever it takes to get undo/redo working for ^J too.

> The function do_justify() doesn't call dowrap() though.

I know -- first I wrote "shouldn't" and then replaced it with "doesn't",
but forgot that this doesn't make sense for do_justify().

> Seems like the
> dowrap() function was created prior to the undo/redo functions.

Far before.

> It's
> a goofy function that only allows a single undo, and only if the undo
> shortcut is applied before any other keystrokes.

It was probably made for the case of accidentally hitting ^J instead
of ^H or ^K.  Or maybe simply because ^J can change a lot of stuff
and it would be terrible to have to undo all that by hand.

Benno

-- 
http://www.fastmail.fm - Same, same, but different...