nano-devel
[Top][All Lists]
Advanced

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



reply via email to

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