CLI undo edit?

[Neil Williams]

On Monday 08 August 2005 9:47 am, Derek Atkins wrote:
> Neil Williams <linux at codehelp.co.uk> writes:
> > If the undo list is retained within the book and only referenced from
> > that book, this would provide sufficient segregation.
>
> I presume by "retained" you mean "in core" and not "in storage"...

Yes, the list itself would be part of the QofBook struct and accessed via an 
API exposed via qofbook.h - the undo list itself could be stored in a similar 
manner to the current logs if that was useful. Depends on the SQL backend - 
if we're all using immediate commit in SQL then would there be any need for 
the logs at all?

> IMHO the undo/redo list should be size-bounded, not unlimited.

I was wondering about that too. So a hard-coded limit of, say 300 - should 
that be configurable? or an absolute limit and configurable only downwards?

> Also, it should not necessarily depend on the dirty flag.

Maybe it would use the event interface instead - every modify or create event 
would be added to the undo list?

Should the name reflect that?
void qof_book_undo_event(QofBook *book);
?
or just 
void qof_undo(QofBook *book);
?

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050808/1dfbf2f8/attachment.bin