Theme colors with inline TOML comments render as black text (colors.toml parser doesn't strip trailing comments)

[Chimmy89]

What happened

Omawrite reads background/foreground/accent/selection/mode from ~/.local/state/omarchy/current/theme/colors.toml (Backend::loadOmarchyTheme() in src/backend.cpp). If a theme writes an inline comment after the color value on the same line — which is valid TOML — the parser doesn't strip it, so the resulting "color" string is garbage, QColor fails to parse it, and the text (or background) silently renders as black.

Repro

Given this line in colors.toml (an entirely normal, spec-compliant way to annotate a hex color):

foreground = "#EDE6D6"        # some description of the color

loadOmarchyTheme()'s line parser does:

QString value = line.mid(equals + 1).trimmed();
if (value.size() >= 2
        && ((value.front() == QLatin1Char('"') && value.back() == QLatin1Char('"'))
            || (value.front() == QLatin1Char('\'') && value.back() == QLatin1Char('\''))))
    value = value.mid(1, value.size() - 2);

(src/backend.cpp around lines 593–602)

value ends up as the literal string:

"#EDE6D6"        # some description of the color

Since the string no longer ends with a " (it ends with the comment text), the quote-stripping branch never triggers, and m_themeForeground is set to that whole garbage string. QColor(m_themeForeground) is then invalid, which renders as black — both for the editor's main text color and, since background is parsed the same way, for the window background too. Only lines with no trailing comment parse correctly.

I hit this because my Omarchy theme's colors.toml documents each color with a short inline comment (a very natural thing to do — TOML explicitly supports comments after a value on the same line), e.g.:

background = "#1A1B17"        # ink, warmed
foreground = "#EDE6D6"        # unbleached cloth
accent     = "#F7F2E7"        # shell-white pigment

Every one of background/foreground/accent came out invalid → rendered black-on-black, to the point of being unreadable without selecting the text to highlight it.

Suggested fix

The parser only handles the case where the comment is on its own line (line.startsWith('#') is checked before the = split). It should also strip a trailing # ... comment from the value portion of a key = value line, ideally comment-aware of quoted strings (so a literal # inside a quoted value, if that's ever a case you support, isn't mistaken for a comment start). A minimal fix: after extracting value, if it starts with a quote character, find the matching closing quote and discard everything after it, rather than assuming the value ends at end-of-line.

Workaround

Moving the comment to its own line above the key (rather than trailing it) avoids the bug entirely, and is what I've done for now. Filing this so it doesn't bite the next person who writes an inline comment in their theme's colors.toml — I couldn't find it mentioned in the existing issues.

Version

omawrite 0.5.0-1 (Arch/Omarchy package)

[omarchybot]

Confirmed, and your diagnosis is right down to the mechanism. Backend::loadOmarchyTheme() unwraps a value only when it both begins and ends with a quote (src/backend.cpp:599-602 on master), so a trailing comment leaves the value ending in the comment text and the quotes survive with it. foreground = "#EDE6D6" # unbleached cloth becomes the literal string "#EDE6D6" # unbleached cloth, and on Qt 6.11.2 a QML color property coerces that to opaque black — checked directly rather than inferred. MarkdownHighlighter builds a second invalid QColor from the same string at src/markdownhighlighter.cpp:46-50, so the syntax highlighting goes black with it.

Two things beyond what you found, from checking the rest of the same parser:

• Surrounding whitespace, single-quoted values, CRLF line endings and [table] headers are all already handled: the line is trimmed, and a header has no = so it is skipped. What is not handled is table scope — the parser has no notion of which table it is in, so a background under some other [table] would still be picked up. No published theme uses tables, so that one is latent rather than live.
• The # you flagged as needing care is not hypothetical. Every colour in every shipped theme is a quoted "#rrggbb", so the hash is inside the quotes. A fix that truncated the value at its first # would empty all of them. The fix takes a quoted value as ending at its closing quote instead, and there is a test for exactly that case.

The silent failure was worth correcting too: an unparseable value overwrote a perfectly good default and the editor went black with nothing to say why. Colours QColor cannot read now leave the built-in default in place. Those defaults also had to move — they were picked from the previous mode before mode was parsed, so a light theme with one malformed colour would have got the dark default painted onto a white page.

The fix is up as #34, off master. Unquoted values stay verbatim there, matching Omarchy's own parser in bin/omarchy-theme-color, so a theme writing background = #1a1b26 without quotes keeps working.

This was reviewed twice: once by me, and independently by Codex at xhigh reasoning. Codex confirmed the mechanism and traced the consumers, and contributed the mode-ordering problem above, which the first version of the fix had. It also noted that Qt documents the result of using an invalid QColor as undefined, so "black" is what this build does rather than a guarantee, and that Material.accent rejects an invalid value rather than blackening. Whether the fix lands is the maintainer's call.