Bug 416393

SUMMARY

If a non-normal font weight is selected (e.g. "Light"), and bold is explicitly set to 0 in katesyntaxhighlightingrc for a particular style item, it will be rendered as Normal instead of Light.

STEPS TO REPRODUCE

1. In Kate, choose a font and set its weight to Light
2. Choose a file which will be syntax highlighted and which has a comment in it (e.g. choose a C++ file with /* Some text */ in it)
3. Open ~/.config/katesyntaxhighlightingrc in an editor - modify the Comment line for both the "Default Item Styles - Schema [Your Style]" and the language you chose (e.g. "Highlighting C++ - Shema [Your Style]").  This line is a comma-separated list of values.  The first two entries are colors, and the third is a boolean specifying bold or not.  0 or empty means no, 1 means yes.  Set it explicitly to 0 (not empty)
4. Ensure all other bold style items in both sections are EMPTY, not 0
5. Open your chosen source file in kate

OBSERVED RESULT

The comment is bolder than the rest of the text.

EXPECTED RESULT

The comment is the same weight as the rest of the text.

ADDITIONAL INFORMATION

Here's what's happening: The following code is in katesyntaxmanager.cpp:

if (!tmp.isEmpty()) {
    i->setFontBold(tmp != QLatin1String("0"));
}

If the bold option is empty, then this block won't run.  If it's anything but 0, setFontBold(true) is called; and if it's 0, setFontBold(false) is called.

The problem is that setFontBold() looks like this:

void Attribute::setFontBold(bool bold)
{
    setFontWeight(bold ? QFont::Bold : QFont::Normal);
}

If it's not bold, it's assumed that it's normal.  But a light font was selected, so the resulting font is thicker than it ought to be (Normal being thicker than Light).  If the bold option is empty instead of 0, the method is never called, so the font remains Light.

The obvious fix is to only call setFontBold(true), and only when the entry is non-empty and non-zero.  But there are other callers to setFontBold(), so this wouldn't really address the underlying problem.  I think the real fix would be for setFontBold() to have knowledge of the current font selection: if it's called with false, set it to the user's selected weight; if it's true, set it to the "next bolder" weight.  But I don't know if that's possible.