Abdelrazak Younes wrote:

> Alfredo Braunstein wrote:
>> Abdelrazak Younes wrote:
>> 
>>> Alfredo Braunstein wrote:
>>>> Abdelrazak Younes wrote:
>>>>
>>>>> I am not sure that registering every single DocIterator would be any
>>>>> more efficient that my signal/slot solution. At the end you will have
>>>>> to go through a table.
>>>> Small remark: note that not all DocIterators need to be stable (mainly
>>>> cursors, maybe also bookmarks & error marks), one could have a class
>>>> derived from DocIterator for that purpose.
>>> I agree but it's more work than my signal based solution which is
>>> assured to work in all cases. I tell you what, in order to save the bits
>>> Andre is worried about I am going to remove the signal from Inset and
>>> transfer them to InsetText and InsetMathHull. In 1.6, we can think of
>>> this other solution. But really, my solution is cheap in terms of CPU
>>> and it will be cheaper in terms of memory when I do the change described
>>> above.
>> 
>> In general terms Abdel I agree that it is not so bad if it really works
>> (in order to implement a "correct" solution (TM) having something working
>> even if inefficient is /good/, not bad), but are we sure that it works in
>> all cases?
> 
> At least I have tested it with every test I could think of.
> 
> 
>> In general it seems wrong to me that invalidation of cursors is only
>> due to inset destruction.
> 
> Not only, this case below can invalidate cursor:
> 
>> For instance, put a cursor inside an inset, then
>> in another window add or remove some text before the inset so the
>> position of the inset changes... no destruction occurs, but is the cursor
>> still valid? (sorry don't have svn to check here.)
> 
> No, and that is the purpose of the new method
> DocIterator::FixIfBroken(). This will first validate the validity of the
> CursorSlice (thus the existence of the insets) then the validity of the
> text index, then the one of the cursor row, then the position in this row.

Ah! So you *are* sort of implementing the dociterator registering thing in a
sense: you just manually keep track of a few dociterators  ;-). 

Btw, just downloaded and had a look at the code, I think that the checks are
not done correctly, you should for instance get sure that the pos of the
inset is the one pointed in the parent slice, not just check that pos <=
lastpos. Otherwise you still get an invalid iterator methinks.

Just a though... why do we need the invalidation signals at all? ...couldn't
we go in fixIfBroken from the top to the tip of the DocIterator checking
that there is an inset an the given position in the paragraph, and that the
pointer of that inset is the one in the iterator in the next slice (as well
as the idx, pit, pos checks)?

A/


Reply via email to