Georg Baum wrote:
> > Because André passed the gui name of the color to the colorinset, and
> > this gui name gets translated. See math_nestinset.C: 396
> > if (font.color() != LColor::inherit) {
> > MathAtom at = createMathInset("color");
> > asArray(lcolor.getGUIName(font.color()), at.nucleus()->cell(0));
> > cur.handleNest(at, 1);
> > }
>
> But this does not fit in the overall scheme: Normally every text contained
> in a math atom is valid LaTeX. I am not sure whether this is assumed at
> other places in the code.
I know. And I agree basically. I just didn't want to rewrite the whole thing
just for the bugfix.
> > An alternative is to use the LyX name here instead. LaTeX name is no
> > option, because there is no LColor getFromLaTeXName (and we need the
> > LColor to set the text color).
>
> If you look at LColor.C you'll see that the LaTeX name of all LaTeX is
> equal to the LyX name, so it does not matter whether we use the LaTeX or
> LyX name :-)
Yes, I thought about this too. But is this safe for the future? I.e. will lyx
color be always the same as latex color?
> The current mixture of GUI/LaTeX names is a mess. The only clean way out of
> it is IMHO to store only LaTeX names.
> I propose the attached fix.
I'm fine with this, except for the \normalcolor thing (see below).
> The only thing I am not sure about is the
> setPosCache bit, but I agree with you to remove cell(0) from display. Then
> it is not possible anymore to create invalid colors, and the evil popping
> up color names are gone.
Great!
> We have still one problem (also without the patch): cursor movement via
> arrow keys goes always through cell(0), even if it is not displayed.
Hm, it should be possible to "lock" this cell only (or if not, force the
cursor to move outside).
> And then there is the problem with \normalcolor: This cannot be read
> anymore. Why did you not simply write cell(1) without any color in this
> case?
Because if you have nested colorinsets, the color of the inner inset has to be
reset to \normalcolor.
> >> | if (normalcolor(cell(0)))
> >> | os << "{\\normalcolor " << cell(1) << '}';
> >> | else if (oldstyle_)
> >> | - os << "{\\color" << '{' << cell(0) << '}' << cell(1) <<
> >> | '}'; + os << "{\\color" << '{' << color.c_str() << '}' <<
> >> | cell(1) << '}';
> >>
> >> c_str not needed here.
> >
> > without c_str, I get compiler errors.
>
> Maybe because os is a special mathed WriteStream and no std::ostream?
Yes, probably.
Jürgen
