[203_27] 公式带前景色时，使用部分颜色时导出 LaTex 代码会出错

[jackmath5261-bit]

No description provided.

[MoonL79]

测试文件只有输入，没有显示当前导出的实际 LaTeX 结果。建议补充：

• 当前 PR 修复后，导出 LaTeX 的实际结果是什么
• 与修复前的对比

[MoonL79]

PR #3036 Review - [201_100] 公式带前景色时，使用部分颜色时导出 LaTex 代码会出错

Bug 修复逻辑清晰，cond 条件重排合理。

已在对应行留了意见：测试文件缺少实际 LaTeX 导出结果的对比，建议补充以便验证修复效果。

Scheme 代码风格规范，右括号标记正确。

[greptile-apps]

Greptile Summary

This PR fixes a LaTeX export bug where formulas using partial (hex) foreground colors were emitted as \color[HTML]{AA6666}ddd — an [HTML] optional-argument form without curly-brace grouping around the colored content — instead of the correct {\color{#AA6666}{ddd}} form.

Key changes:

• tmtex-decode-color: The "HTML" color case no longer requires force-html to be set; it unconditionally returns a plain string "#RRGGBB" (using xcolor's # prefix shorthand) instead of the old list ((!option "HTML") "RRGGBB").
• tmtex-make-color: The HTML color path now flows through the existing tmcolor macro (which already provides correct {\color{...}{...}} wrapping), instead of the hand-rolled !group/!append construction that omitted the content group.
• A regression test and .tmu fixture are added to verify named, hex, and named-color exports all produce properly grouped LaTeX.

Notes:

• The (list? ltxcolor) branch in tmtex-make-color is now dead code: after the fix, tmtex-decode-color always returns a string, so the list branch (and the new (!group ,arg) inside it) can never be reached.
• The removal of the force-html guard on the HTML case is an unintentional but benign side-effect that also normalizes hex colors for \colorbox, \fcolorbox, and ornament-color callers.

Confidence Score: 4/5

Safe to merge; the fix is correct and well-tested, with only minor dead-code and documentation nits remaining.

The core logic change is sound: HTML colors now route through the tmcolor macro which correctly groups the colored argument. The regression test validates all three color paths. The two remaining concerns (dead code in tmtex-make-color and the implicit widening of the HTML branch to non-force-html callers) are non-blocking P2 style/maintenance items that don't affect correctness of the fix.

Both tmtex.scm files (TeXmacs/progs/ and TeXmacs/plugins/latex/progs/) contain the dead (list? ltxcolor) branch; consider cleanup in a follow-up.

Important Files Changed

Filename	Overview
TeXmacs/progs/convert/latex/tmtex.scm	Core fix: HTML colors now always return a "#RRGGBB" string via tmtex-decode-color, routing them through the tmcolor macro which correctly emits {\color{#RRGGBB}{arg}}. The old (list? ltxcolor) branch is now dead code; the (!group ,arg) addition is unreachable.
TeXmacs/plugins/latex/progs/convert/latex/tmtex.scm	Identical changes to the progs version — same fix, same dead code concern. Both files are kept in sync.
TeXmacs/tests/203_27.scm	New integration test; checks both the fixed \color{#AA6666}{ddd} output and the absence of the old broken \color[HTML]{AA6666} form. Test coverage is adequate for the bug being fixed.
TeXmacs/tests/tmu/203_27.tmu	New test fixture containing three equations with named, hex (#a66), and named colors; drives the regression test.
devel/203_27.md	Developer documentation describing the bug, expected vs. actual LaTeX output, and how to run the test. Missing trailing newline at end of file.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["tmtex-make-color(val, arg)"] --> B["tmtex-decode-color(val, #t)"]
    B --> C{cm = ?}
    C -- "HTML (s starts with #)" --> D["string-append '#' html-color->latex-xcolor(s) → '#AA6666' (string)"]
    C -- "none + force-html" --> E["recursive call with get-hex-color(s)"]
    C -- "texmacs" --> F["string-replace s ' ' '' → named string"]
    C -- "x11names" --> G["recursive call with get-hex-color(s)"]
    C -- "else" --> H["string-replace s ' ' '' → named/colormap string"]
    D --> I{list? ltxcolor}
    F --> I
    H --> I
    I -- "true (DEAD CODE after fix)" --> J["(!group (!append (color ...) (!group arg))) → {\\color[...]{...}{arg}}"]
    I -- "false (ALL paths now)" --> K["(tmcolor ltxcolor arg)"]
    K --> L["tmcolor macro expands to {\\color{ltxcolor}{arg}}"]

Loading

_{Reviews (1): Last reviewed commit: "测试用例" | Re-trigger Greptile}

[greptile-apps]

Dead code branch after the HTML-path change

After the refactor, tmtex-decode-color always returns a string — the "HTML" branch now returns (string-append "#" ...), and every other branch also returns a string or recurses (which also now returns a string). Therefore (list? ltxcolor) is always #f, and the (!group (!append (color ,@ltxcolor) (!group ,arg))) line can never be reached.

The (!group ,arg) addition that was part of this PR's fix is consequently also dead code. If the grouping fix is needed, it should be applied to the active code path (the else branch via tmcolor), although the tmcolor macro definition already wraps arg in (!group 2) — so grouping is already handled there.

Consider either removing the dead list branch, or documenting why it is preserved as a future extension point.

[greptile-apps]

force-html guard removed from HTML branch — silent behavior change for colorbox/fcolorbox/ornament-color

Previously the HTML case was gated on (nnull? force-html), so callers that pass no force-html argument (lines 2371, 2374, 2699 — used for \colorbox, \fcolorbox, and ornament-color) would fall through to the else branch and return the raw string (e.g. "#a66") unchanged. Now those callers also receive the normalized "#AA6666" form.

This is probably an improvement (the normalized 6-digit hex is more portable with xcolor), but it is an unintentional side effect. The force-html variadic parameter now has no effect on the HTML path at all — only the none recursion still consults it. Consider renaming it to force-expand or adding a comment documenting that its scope has narrowed, to prevent future confusion.