Support underline colors

[nihaals]

Underline colors are supported in at least Kitty, Ghostty and Mintty and are a requirement for a complete implementation of the terminal graphics protocol. Since you can't simply add the ANSI codes part of your Segment text, it's much more work to implement this part of the protocol in Rich (and might not be possible using public APIs?). This affects libraries such as textual-image.

For the protocol to be implemented cleanly, it would also need to be possible to set a highlight color without actually enabling an underline/specifying an underline style.

---

In case this helps someone, I eventually managed to get an implementation that works in both Rich and Textual (and could be extended for other unimplemented/unsupported ANSI codes):

def monkeypatch_style_add(self: Style, style: Style | None) -> Style:
    # https://github.com/Textualize/textual/blob/eed9aa0ccc3ae263e56b38f9763e556572c0496d/src/textual/widget.py#L191-L195
    # `Style.__add__` resets `_ansi` which breaks our custom ANSI codes
    if style and style._ansi and style._ansi.startswith("58;2;"):
        return style

    # https://github.com/Textualize/rich/blob/4d6d631a3d2deddf8405522d4b8c976a6d35726c/rich/style.py#L753-L755
    combined_style = self._add(style)
    return combined_style.copy() if combined_style.link else combined_style


rich.style.Style.__add__ = monkeypatch_style_add


def monkeypatch_style_hash(self: Style) -> int:
    # Styles cached based on hash but excludes our custom ANSI codes
    # This causes all our styles to become the first style we return
    # https://github.com/Textualize/rich/blob/4d6d631a3d2deddf8405522d4b8c976a6d35726c/rich/style.py#L437-L441
    if self._hash is not None:
        return self._hash
    if self._ansi and self._ansi.startswith("58;2;"):
        self._hash = hash(self._ansi)
    else:
        self._hash = hash(rich.style._hash_getter(self))
    return self._hash


rich.style.Style.__hash__ = monkeypatch_style_hash


def style_with_foreground_and_underline_color(
    fg_color: tuple[int, int, int], underline_color: tuple[int, int, int]
) -> Style:
    style = Style()
    fg_color_ansi = [
        "38",
        "2",
        str(fg_color[0]),
        str(fg_color[1]),
        str(fg_color[2]),
    ]
    underline_color_ansi = [
        "58",
        "2",
        str(underline_color[0]),
        str(underline_color[1]),
        str(underline_color[2]),
    ]
    style._ansi = ";".join(underline_color_ansi + fg_color_ansi)
    # https://github.com/Textualize/rich/blob/4d6d631a3d2deddf8405522d4b8c976a6d35726c/rich/style.py#L336-L338
    style._null = False
    return style

[tayfuryldz]

Your workaround highlights why _ansi is a difficult extension point: in Style it is an internal cache of the generated SGR sequence, not an independent arbitrary-ANSI field. Several style operations deliberately clear it, and hashing/composition are based on the modeled style attributes. Storing underline-color state there therefore makes equality/hash/composition semantics incomplete, as you've already encountered.

A first-class implementation would be safer if underline color were modeled like foreground/background color in Style itself, then emitted as SGR 58 during _make_ansi_codes(). That would let copy/combine/hash behavior carry the value rather than requiring special handling for a cached string. It would also allow underline color without forcing the underline attribute, which is useful for protocols that repurpose that terminal state.

So I would avoid relying on _ansi as a public escape hatch in a library: it can be invalidated by normal style operations. The request makes sense as a Style model/API addition if Rich wants to support SGR 58 explicitly.