On Sun, Jul 09, 2006 at 05:54:18PM +0200, Abdelrazak Younes wrote:
> void MathNestInset::cursorPos(CursorSlice const & sl, bool /*boundary*/,
> int & x, int & y) const
> {
> // FIXME: This is a hack. Ideally, the coord cache should not store
> // absolute positions, but relative ones. This would mean to call
> // setXY() not in MathArray::draw(), but in the parent insets' draw()
> // with the correctly adjusted x,y values. But this means that we'd have
> // to touch all (math)inset's draw() methods. Right now, we'll store
> // absolute value, and make them here relative, only to make them
> // absolute again when actually drawing the cursor. What a mess.
>
> The comment above scares me a bit to say the least.
The alternative would be either no comment or fixing it properly.
The roadmap is sketched in the comment ;-)
> The error comes from math_data.C:
>
> L129: x = pt.x_ - pt2.x_ + ar.pos2x(sl.pos());
>
> Here ar.pos2x(sl.pos()) gives a big negative number because the width_
> has not been initialized apparently: -1163005939 (h=0 though).
So it is called before the first call to metrics()?
> Then in MathArray::pos2x(size_type pos, int glue):
>
> L357 if ((*it)->getChar() == ' ')
>
> The default virtual getChar() is called, the one in math_inset.h:
>
> /// return the content as char if the inset is able to do so
> virtual char getChar() const { return 0; }
>
> So my conclusion is that it does not point to the correct data. This is
> weird as the size of the vector is 1. So it surely have been filled in
> somewhere.
>
> Then of course, (*it)->width() gives a bad value (-1163005939).
>
> Someone knows about that stuff?
I should. In theory.
Andre'
