Andre Poenitz wrote:
> See attached. Basic operations on nested text insets work, tables and
> some of the mouse related stuff is defunct but not nearly as bad as last
> time.
>
> Someone willing to help me to fix that mess?
I'd like to help, but I'm afraid I don't understand the assignement. ;-)
> It's probably mostly making sense of the stuff in '#ifdef LOCK' and
> replacing it with a 'modern' equivalent. (LOCK is undefined, so this is
> a #if 0 in disguise.)
For instance in this piece:
> bool BufferView::lockInset(UpdatableInset * inset)
> {
> + return true;
> +#ifdef LOCK
> if (!inset)
> return false;
>
> @@ -420,6 +422,7 @@ bool BufferView::lockInset(UpdatableInse
> }
> }
> return false;
> +#endif
> }
Should we find the said inset and place the Cursor inside it? Or
"eliminating" the function as it's done is ok?
Maybe we should fix the callers to not call lockInset, but place the cursor
appropriately instead?
As you'll notice, I'm slightly lost.
If I understand correctly, we want to maintain the invariant of "the locking
path" being equal to the path stored in Cursor. With the locking stuff
active, this works correctly. Now that you deactivate parts of the locking
stuff, this doesn't work anymore (and moreover, cannot be checked, because
we don't have locking anymore).
Does the cursor dispatch alone works correctly?
I think that we should start be eliminating "users" of the locking stuff
(the biggest being dispatch), but leaving the locking infrastructure intact
for checking. But maybe I understood everything upside down. ;-)
Alfredo
