the following, beginUndoGroup() recordUndo() doaction1() recotdUndo() doaction2() endUndoGroup()textUndo() will undo both doaction2 and doaction1 (in this order). This is done by assigning a group_id to each UndoElement and handling consecutive
elements with same id in one operation.
What is it good for?1/ some operations (like inserting a float over a selection) generate several undo elements on the stack. This is now completely transparent to the user.
2/ some operations (e.g. replace all) save the whole document in the undo stack. This can be a problem when working on a big document [1]. Undo groups allows
to do many small operations instead. The following patch does not implement part 2/ of the plan as it is. AllrecordUndoFullDocument uses should be audited and either replaced with individual recordUndo operations or by a new recordUndoDocumentParameters method (am I wrong
that it would be enough when editing BufferParams?).The patch is actually simpler than it seems since I only introduce a new indirection between the kernel and the undo machinery. I'd be tempted to propose it for 1.6, but
I understand that not everybody would be thrilled by this idea :) Comments and testers welcome.
undogroups.diff
Description: Binary data
JMarc[1] reallife example: http://thread.gmane.org/ gmane.editors.lyx.general/48388