Alfredo Braunstein wrote: > iterator.[Ch]: > > I need this lockPath stuff. It is needed to place a cursor given some > position in the document tree. In the old scheme, inset were locked > sequentially following the cursor movement. [[Implemented in ParIterator for > simplicity, because we have random access to the stack (PosIterator has a > real stack)]]
I mannaged to put that phrase in the most strange order ;-) > Now we want to do all text operations without caring about locking and > cursors, and then on a final step lock all the branch in the tree (and > place the cursor). It is ugly, but temporary anyway (will die with the > locking). It is a const method. > > PosIterator.[Ch]: > > A pair of stupid helpers (I promess to later study how to make PosIterator > a forward_iterator and remove these) > > bufferview_funcs.[Ch]: > > a simple helper to put a selection in an arbitrary point in the tree > (using lockPath) Can I apply the patch? Let me add that with the above, the following patch fixes the undo crash detected by Kornel (so it solves a problem that we have already, i.e. how to put a cursor in an arbitrary point in the tree. It encapsulates all the dirty locking work in one place). Regards, Alfredo Index: undo.C =================================================================== RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/undo.C,v retrieving revision 1.25 diff -u -p -u -r1.25 undo.C --- undo.C 29 Oct 2003 12:18:08 -0000 1.25 +++ undo.C 3 Nov 2003 09:06:11 -0000 @@ -200,12 +200,8 @@ bool performUndoOrRedo(BufferView * bv, // rebreak the entire lyxtext bv->text->fullRebreak(); - InsetOld * inset = pit.inset(); - if (inset) { - // magic needed to cope with inset locking - bv->lockInset(dynamic_cast<UpdatableInset *>(inset)); - } - + pit.lockPath(bv); + finishUndo(); return true; }