On Fri, 2005-11-04 at 14:42 +0100, Jean-Marc Lasgouttes wrote: > >>>>> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > Martin> The attached patch is perhaps more what you had in mind. It > Martin> forces the selectionBegin and selectionEnd iterators to be of > Martin> the same depth. Works for both cases: selecting to the left > Martin> and to the right. I believe that covers all bases. > > I do not understand what you are doing. CursorSlice::operator< is > supposed to assert if the slices are not on the same inset. So if you > code works, it means that top() and anchor() do point to the same > inset. So which is the resize useful?
Look at the loop in text2.C at line 475. The test dit != ditend. This
will never trigger for different-sized dit, ditend (i.e. different
length vectors of cursor slices). --> infinite loop.
> Hmmm... I see, this is the special code in anchor():
>
> CursorSlice LCursor::anchor() const
> {
> BOOST_ASSERT(anchor_.depth() >= depth());
> CursorSlice normal = anchor_[depth() - 1];
> if (depth() < anchor_.depth() && top() <= normal) {
> // anchor is behind cursor -> move anchor behind the inset
> ++normal.pos();
> }
> return normal;
> }
>
> Aren't you supposed to play similar ++ tricks like that?
>
> And why is it true that anchor_.depth() >= depth().
>
> It seems to me that uses of selBegin/End are safe, but that
> selectionBegin/End (which are used much less often) may be broken.
I don't understand this at all.
All I know is that my patch works, and that I thought I understood why.
Now I'm not so sure anymore.
Anyway, a working patch for 1.4. Shouldn't we just commit and forget
about the luxury of understanding it?
;-)
- Martin
signature.asc
Description: This is a digitally signed message part
