[Top][All Lists]

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

Re: [Nano-devel] one more undo failure

From: Mark Majeres
Subject: Re: [Nano-devel] one more undo failure
Date: Sat, 21 Jun 2014 14:56:17 -0700

On 6/21/14, Benno Schulenberg <address@hidden> wrote:
> Hi Mark,
> On Sat, Jun 21, 2014, at 17:52, Mark Majeres wrote:
>> Yes, undoing/redoing some actions, such as cut/paste/file insert will
>> mark a selection prior to calling do_cut.  IMO, editing the file while
>> an area is marked/selected is a strange thing to do.
> But people do strange things, and it is something that I would do:
> while busy selecting an area I want to move, I see a word I want
> to change, I will do that, and then proceed to make the selection.
> Having the mark on does not bother me.
> Thus, undoing the word change should not unset the mark unless
> absolutely necessary to make the undo work properly.
>> I don't think
>> anyone will expect anything less.  Unmarking before undo/redo only
>> some of the time would be inconsistent.
> Hm.  Maybe some more unsettings of the mark can be left out?

Well, the mark begin/end for the line and x_locations can be saved and
restored then,  but it seems like this will lead to a lot of frivolous
code.  It's very possible for the lines/locations to be very different
after the undo/redo.

> By the way, in redo_cut() there is a free(cutbuffer).  Shouldn't
> that be a free_filestruct(cutbuffer), like in undo_cut()?

Yes, it should.  That's a potential leak point, but it would be better
replaced by cutbuffer_reset().  This line in undo_cut() is also a leak

cutbuffer = copy_filestruct(u->cutbuffer);

There's likely to be other leaks like these two.  There should really
be a cutbuffer.c module with a static cutbuffer variable and access
methods, instead of the current extern cutbuffer with global access.

> And the lines around there, fiddling witj openfile->mark_set,
> would it be nicer to regroup these as:
>     if (!ISSET(CUT_TO_END))
>         openfile->mark_set = TRUE;
>     else
>         openfile->mark_set = u->mark_set;
>     openfile->mark_begin = fsfromline(u->mark_begin_lineno);
>     openfile->mark_begin_x = (u->xflags == UNcut_cutline) ? 0 :
> u->mark_begin_x;

Yeah, that looks like a good idea too.

reply via email to

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