[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
point:
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.