feat(render): add configurable attribute colors for bold, italic, and underline #2264

spaceone commented 2026年01月17日 03:45:01 +01:00

Introduce optional color theme entries for bold, italic, and underline text
when the foreground color is default. This allows legacy applications using
SGR attributes instead of explicit colors to be rendered with user-defined
attribute colors. Brightening via bold_in_bright is suppressed when an
explicit attribute color is applied.

This adds compatibility with the rxvt-unicode settings colorBD,
colorIT and colorUL.

Fixes: #2261

Introduce optional color theme entries for bold, italic, and underline text when the foreground color is default. This allows legacy applications using SGR attributes instead of explicit colors to be rendered with user-defined attribute colors. Brightening via `bold_in_bright` is suppressed when an explicit attribute color is applied. This adds compatibility with the rxvt-unicode settings `colorBD`, `colorIT` and `colorUL`. Fixes: #2261

craigbarnes commented 2026年01月17日 13:58:15 +01:00

I noticed on IRC you mentioned "vim, git, weechat, tmux" as examples of apps where you'd want to use these options. I'm not sure if I missed some extra context, but one question that comes to mind is: why not configure colors/attributes exactly how you want them in the apps themselves?

Is this really about making bold turn into green because "that's what I did in rxvt" or is there more to it than that? The reason I ask is because bold-text-in-bright is much the same thing and already causes lots of confusion.

If these options are added, I think we need a clearer justification on the record than "it's for legacy apps". We need a falsifiable example where we can either say "ok, that's a valid use case" or "no, because you can just configure the app the sensible way". At the very least I think they should be buried in the [tweaks] section and/or have their use clearly discouraged in the manual.

I noticed on IRC you mentioned "vim, git, weechat, tmux" as examples of apps where you'd want to use these options. I'm not sure if I missed some extra context, but one question that comes to mind is: why not configure colors/attributes exactly how you want them in the apps themselves? Is this really about making bold turn into green because "that's what I did in rxvt" or is there more to it than that? The reason I ask is because `bold-text-in-bright` is much the same thing and already causes lots of confusion. If these options are added, I think we need a clearer justification on the record than "it's for legacy apps". We need a falsifiable example where we can either say "ok, that's a valid use case" or "no, because you can just configure the app the sensible way". At the very least I think they should be buried in the `[tweaks]` section and/or have their use clearly discouraged in the manual.

spaceone commented 2026年01月17日 17:07:14 +01:00

Thank you for the immediate feedback!

why not configure colors/attributes exactly how you want them in the apps themselves?

1. Because I switch between colorschemes (dark and light) and the colors i would have to configure in each app wouldn't fit for both variants.
2. Also when selecting text, there is a difference between the concept of configuring the app and the actual effect of switching bold color: foot currently doesn't just switch foreground with background but uses the foreground-color as text and regular7 as background (see second screenshot below).
3. And I don't think every app supports all settings and I have a lot more config options to maintain instead of just one for the terminal.

Is this really about making bold turn into lime green because "that's what I did in rxvt" or is there more to it than that? The reason I ask is because bold-text-in-bright is much the same thing and already causes lots of confusion.

I think it's just that, yes.
bold-text-in-bright is even more essential to me. It makes bold text easily recognizable. I makes my workflow a lot faster as my brain is used to some kind of speed-reading-with-color-context.

If these options are added, I think we need a clearer justification on the record than "it's for legacy apps". We need a falsifiable example where we can either say "ok, that's a valid use case" or "no, because you can just configure the app the sensible way".

The term "legacy apps" probably don't fit exactly, as the tools I use are common tools.
Hm, how would I give the falsifiable examples?
Let's start with one example here: git.

grafik

On the left, there is the original urxvt and on the right foot without bold option. You can see that the diff-markers are bold-foregorund-green and not easy distinguishable from the text/content (applies to green, grey and blue foreground colors).

The selected text below is also displayed differently, previously easier to read.

Additionally I use a very small font (DeJaVu 9 point), which in other contexts make bold indistinguishable from regular foreground.

Let's try to configure git accordingly:

[color "diff"]
 meta = white bold
 frag = cyan
 old = red bold
 new = brightgreen bold

grafik

→ As mentioned above, the selection differs much.

At the very least I think they should be buried in the [tweaks] section and/or have their use clearly discouraged in the manual.

I do whatever you(maintainers) want, but it feels like that's a direct color related setting. Also foot now offers dark and light color themes. In another colorscheme I don't use bold-to-text.
Also if it makes the code/tests more complex (didn't have a look, but there were some color-specific-functions), I wouldn't prefer this.

The reason being that it weakens the whole terminal ecosystem when authors of TUI apps have to consider things like "but what if bold is actually mapped to a color that's invisible against this background"?

OK, I would see the user of that config-option as the risk taker here. I am using that since 15 years and I never saw any problems before.

Thank you for the immediate feedback! > why not configure colors/attributes exactly how you want them in the apps themselves? 1. Because I switch between colorschemes (dark and light) and the colors i would have to configure in each app wouldn't fit for both variants. 2. Also when selecting text, there is a difference between the concept of configuring the app and the actual effect of switching bold color: foot currently doesn't just switch foreground with background but uses the foreground-color as text and `regular7` as background (see second screenshot below). 3. And I don't think every app supports all settings and I have a lot more config options to maintain instead of just one for the terminal. > Is this really about making bold turn into lime green because "that's what I did in rxvt" or is there more to it than that? The reason I ask is because `bold-text-in-bright` is much the same thing and already causes lots of confusion. I think it's just that, yes. `bold-text-in-bright` is even more essential to me. It makes bold text easily recognizable. I makes my workflow a lot faster as my brain is used to some kind of speed-reading-with-color-context. > If these options are added, I think we need a clearer justification on the record than "it's for legacy apps". We need a falsifiable example where we can either say "ok, that's a valid use case" or "no, because you can just configure the app the sensible way". The term "legacy apps" probably don't fit exactly, as the tools I use are common tools. Hm, how would I give the falsifiable examples? Let's start with one example here: git.  On the left, there is the original urxvt and on the right foot without bold option. You can see that the diff-markers are bold-foregorund-green and not easy distinguishable from the text/content (applies to green, grey and blue foreground colors). The selected text below is also displayed differently, previously easier to read. Additionally I use a very small font (DeJaVu 9 point), which in other contexts make bold indistinguishable from regular foreground. Let's try to configure `git` accordingly: ``` [color "diff"] meta = white bold frag = cyan old = red bold new = brightgreen bold ```  → As mentioned above, the selection differs much. > At the very least I think they should be buried in the [tweaks] section and/or have their use clearly discouraged in the manual. I do whatever you(maintainers) want, but it feels like that's a direct color related setting. Also foot now offers dark and light color themes. In another colorscheme I don't use bold-to-text. Also if it makes the code/tests more complex (didn't have a look, but there were some color-specific-functions), I wouldn't prefer this. > The reason being that it weakens the whole terminal ecosystem when authors of TUI apps have to consider things like "but what if bold is actually mapped to a color that's invisible against this background"? OK, I would see the user of that config-option as the risk taker here. I am using that since 15 years and I never saw any problems before.

craigbarnes commented 2026年01月18日 12:55:38 +01:00

The reason being that it weakens the whole terminal ecosystem when authors of TUI apps have to consider things like "but what if bold is actually mapped to a color that's invisible against this background"?

In case anyone is wondering, I deleted this quoted comment shortly after sending because I feel like it's a weak example. It kind of puts across my general concern¹ , but I don't think that example in particular is likely to be a problem.

OK, I would see the user of that config-option as the risk taker here. I am using that since 15 years and I never saw any problems before.

Fair enough. I'm not against these options existing per se and I guess they already do in other terminals anyway. I just think the example use case in the docs should be removed, because the way it's worded currently could be taken as legitimizing it instead of discouraging it. IMO it would be better to just discourage its use in general and not mention any use cases.

> The reason being that it weakens the whole terminal ecosystem when authors of TUI apps have to consider things like "but what if bold is actually mapped to a color that's invisible against this background"? In case anyone is wondering, I deleted this [quoted comment] shortly after sending because I feel like it's a weak example. It kind of puts across my general concern[^1], but I don't think that example in particular is likely to be a problem. > OK, I would see the user of that config-option as the risk taker here. I am using that since 15 years and I never saw any problems before. Fair enough. I'm not against these options existing per se and I guess they already do in other terminals anyway. I just think the example use case in the docs should be removed, because the way it's worded currently could be taken as legitimizing it instead of discouraging it. IMO it would be better to just discourage its use in general and not mention any use cases. [^1]: i.e. that there's a certain level of understanding/cooperation between terminals and apps ("the ecosystem"), not just between the terminal and the user [quoted comment]: https://codeberg.org/dnkl/foot/pulls/2264#issuecomment-9938901:~:text=The%20reason%20being,-that

dnkl commented 2026年01月28日 10:38:55 +01:00

I see two aspects to this:

1. What @craigbarnes have mentioned already; the contract between the terminal emulator and the terminal application. Terminal applications need to be able to count on bold being bold. We want to encourage applications to use the bold attribute when bold is the font effect they're going after. We don't want them to use bold instead of brighter colors.

2. While many terminal applications are theme:able, not all are. A user can configure the 256 default terminal colors, and thus "theme" the application anyway. But they cannot easily change bold/italic/underline formatting. This PR "fixes" that.

We don't want to break the terminal emulator/application contract. But I think these options are fine as long as they are clearly documented to state they are for 2), not 1). We don't have to go all out discouraging their use (it'd be better to simply not merge this at all).

In short, I don't really have anything against this PR. That said, it is likely a fairly exotic feature, in the sense that most applications can be themed (which imho is the correct way to "solve" this), and that most people are fine with bold being bold, and nothing else.

I see two aspects to this: 1. What @craigbarnes have mentioned already; the contract between the terminal emulator and the terminal application. Terminal applications need to be able to count on bold being bold. We want to encourage applications to use the bold attribute when bold is the font effect they're going after. We don't want them to use bold instead of brighter colors. 2. While many terminal applications are theme:able, not all are. A user can configure the 256 default terminal colors, and thus "theme" the application anyway. But they cannot easily change bold/italic/underline formatting. This PR "fixes" that. We don't want to break the terminal emulator/application contract. But I think these options are fine as long as they are clearly documented to state they are for 2), not 1). We don't have to go all out discouraging their use (it'd be better to simply not merge this at all). In short, I don't really have anything against this PR. That said, it is likely a fairly exotic feature, in the sense that _most_ applications can be themed (which imho is the correct way to "solve" this), and that most people are fine with bold being bold, and nothing else.

spaceone commented 2026年03月13日 16:27:31 +01:00

FYI: I integrated your wished changes last week.
I think I don't have the infrastructure to do the vtebench benchmark comparision.

FYI: I integrated your wished changes last week. I think I don't have the infrastructure to do the vtebench benchmark comparision.

This pull request can be merged automatically.

You are not authorized to merge this pull request.