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;
}