+1

This whole situation sucks... There are the legacy 8 normal (30-37/40-47) + 8 bright (90-97/100-107) colors. And there are the extended 256 palette colors.

The first 8, if combined with bold, also become bright. E.g. bold + 30 is the same color as 90 (the bright version of color 0 rather than the normal brightness).

The first 16 of the 256-color palette (which are the same colors as the legacy 8+8) on the other hand do not get bright when they are made bold. E.g. 1;38;5;0 is the bold (1) version of the 256-color palette (38;5) of color 0.

So the non-bright but bold combination for the first 8 colors is reachable, but only with the extended 256-color escape sequences.

ncurses, however, relies on terminfo which describes to use the legacy escape sequences for the first 16 colors, hence, the 38/48;5;0-15 escape sequences are never emitted by ncurses. So even though vte can do what you're asking for, apps likely don't know how to do it.

This is indeed a giant legacy cr@p and your proposed option makes us one step closer to something that sucks less (although sure breaks the look of plenty of apps, but it's up to the user which one they prefer). As your link suggests, Solarized pretty much relies on us not to change the color.

We do have an option currently to disable bold. Now I don't see the point in that option and I guess we could remove that. (There's no option to disable italic, underlined, strikethrough either.) Your proposal on the other hand does make sense to me.

*** Bug 774794 has been marked as a duplicate of this bug. ***

[See also bug 655030 comment (14 and) 17.]

Just occurred to me: Since this feature is about whether or not to also apply Brightness in addition to Bold for the first 8 characters, we should codename it BB-8. :-)

Created attachment 365276 [details] [review]
BB-8, vte v1

Created attachment 365277 [details] [review]
BB-8, gnome-terminal v1

Created attachment 365278 [details] [review]
Deprecate allow-bold, vte v1

Created attachment 365279 [details] [review]
Remove allow-bold, gnome-terminal v1

(In reply to Egmont Koblinger from comment #4)
> Just occurred to me: Since this feature is about whether or not to also
> apply Brightness in addition to Bold for the first 8 characters, we should
> codename it BB-8. :-)

;-)

Just a few tiny nits:

Patch 1:

+        pspecs[PROP_BOLD_IS_BRIGHT] =
+                g_param_spec_boolean ("bold-is-bright", NULL, NULL,
+                                      TRUE,

Can we switch that to FALSE? :-)


Patch 2:

+ <property name="label" translatable="yes">_Bold also enables bright</property>
Not sure users know what 'bright' refers to here; maybe "Show bold text in bright colour" or sth like that would be clearer?


Other than that, looks good. Please commit, thanks :-)

(In reply to Christian Persch from comment #9)

> Can we switch that to FALSE? :-)

Way too many utilities/apps change colors then. I'm not comfortable making this the default.

Alsamixer becomes pale and dull, yellow turns to brown, white becomes grey. Coloring of gcc, ls, grep etc. changes. For gcc I changed "01;35" to "01;95" and so on, this is the app-level change that reverts the effect of disabling this new setting. Clang, valac etc. still remain at the darker variants though. Sure there's a whole lot more. It'll be a long journey to convince the majority of such tools to revise their escape sequences accordingly.

Currently this feature is primarly for Solarized (and base16 and other similar schemes) users who also install modified LS_COLORS and so to match the scheme.

(Hence, also in spirit of the planned changes of bug 655030 comment 14 & 17, I've moved the setting to the Color tab.)

> Not sure users know what 'bright' refers to here; maybe "Show bold text in
> bright colour" or sth like that would be clearer?

Definitely! :)

(In reply to Christian Persch from comment #9)

> Not sure users know what 'bright' refers to here; maybe "Show bold text in
> bright colour" or sth like that would be clearer?

Shall I also rename the API?

(In reply to Egmont Koblinger from comment #11)
> Shall I also rename the API?

Not necessary, IMHO.

(In reply to Egmont Koblinger from comment #10)
> > Can we switch that to FALSE? :-)
> 
> Way too many utilities/apps change colors then. I'm not comfortable making
> this the default.
> 
> Alsamixer becomes pale and dull, yellow turns to brown, white becomes grey.
> Coloring of gcc, ls, grep etc. changes. For gcc I changed "01;35" to "01;95"
> and so on, this is the app-level change that reverts the effect of disabling
> this new setting. Clang, valac etc. still remain at the darker variants
> though. Sure there's a whole lot more. It'll be a long journey to convince
> the majority of such tools to revise their escape sequences accordingly.
> 
> Currently this feature is primarly for Solarized (and base16 and other
> similar schemes) users who also install modified LS_COLORS and so to match
> the scheme.

Hmm ok. So the app can avoid this by using other colours instead of the first 8... Should we also introduce some sequence to turn this off?

(In reply to Christian Persch from comment #12)

> Hmm ok. So the app can avoid this by using other colours instead of the
> first 8... Should we also introduce some sequence to turn this off?

My first though was "hell nooooooooo", the new checkbox (its new value) intends to clean up the mess, another escape sequence might just make it even more messy.

But using such an escape sequence, one could make certain apps behave the new way, and certain apps behave the old way. One set ouf of the two would need to be aliased to reside inside a wrapper, or so. (For apps it totally wouldn't make sense to use this escape sequence; they could be fixed not to emit ambiguous ones.)

But again, probably VTE would be the only one implementint this escape sequence, and probably hardly any users would bother with setting up such wrappers in front of their scripts, so I still vote for "no".

Here's something like a support matrix to show how to achieve certain results:

To print in normal font:

  First 8 colors:

    - SGR 30 – 37 or
    - SGR 38;5;0 – 38;5;7

  Next 8 (bright) colors:

    - SGR 90 – 97 or
    - SGR 38;5;8 – 38;5;15

To print in bold:

  First 8 colors:

    - SGR 1;38;5;0 – 1;38;5;7 or
    - SGR 1;30 – 1;37, but it'll only work if this new setting is disabled which isn't the default.

  Next 8 (bright) colors:

    - SGR 1;90 – 1;97 or
    - SGR 1;38;5;8 – 1;38;5;15 or
    - SGR 1;30 – 1;37, but it'll only work if this new setting is enabled (the default for legacy reasons, also the default/only behavior of most, if not all terminal emulators).

---

terminfo doesn't provide direct access to both 30 – 37 and 90 – 97, as well as 38;5;0 – 38;5;15 to apps. Instead, depending on the terminfo description, it offers either the 30 – 37 and 90 – 97, or 38;5;0 – 38;5;15. Currently, at least for "xterm-256color", it's the former.

The output of `tput setaf | cat -v` is:

  ^[[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m

This basically goes like RPN, err, I mean Yoda-speak "if p1 8 less than then output the digit 3 followed by p1, else if p1 16 less than then output the digit 9 followed by p1 8 minus, else output 38;5; followed by p1".

Hence the first 8 entries of the 256-color palette are mapped to SGR 30 – 37, the next 8 are mapped to 90 – 97, and the remaining ones are mapped to 38;5;16 – 38;5;255, and there's no way to emit SGR 38;5;0 – 38;5;15 (that is, no way to reach the bold version of the first 8 colors if the legacy behavior is chosen in the new config option) via terminfo/ncurses using such a terminal definition.

BB-8 submitted.

As for the removal of allow-bold: I personally wouldn't mind it, but there might be a few users out there who (for some mysterious reason) prefers to have it.

How about just removing the UI option for now, waiting for feedback (blaming-flaming) coming in? It'd still be available as a hidden setting for 3.28. If users don't complain, we could entirely deprecate/remove it some later release.

(In reply to Egmont Koblinger from comment #15)
> How about just removing the UI option for now

Fine with me.

> > How about just removing the UI option for now
> Fine with me.

Submitted.

I think we're done with the changes planned for 0.52/3.28. We should get back to the deprecation/removal of allow-bold at some later point, so leaving the bug open.

(In reply to Egmont Koblinger from comment #15)
> As for the removal of allow-bold: I personally wouldn't mind it, but there
> might be a few users out there who (for some mysterious reason) prefers to
> have it.
> 
> How about just removing the UI option for now, waiting for feedback
> (blaming-flaming) coming in? It'd still be available as a hidden setting for
> 3.28. If users don't complain, we could entirely deprecate/remove it some
> later release.

Hello,

I am one of those users who relies on the "allow-bold" option. I use a bold font (Inconsolata Bold) in gnome-terminal which requires the "allow-bold" option to be set to "false" to prevent vte from rendering the already bold font even bolder. I have seen several other people with this configuration, so it doesn't seem to be very uncommon.

I really hope this option will NOT be removed, or if you really insist on doing so, at least provide a different option to set the bold (and maybe italic) font variant separately, so users can find a different solution.

Also this change is rather sneaky, as users who enabled it already won't notice anything for now and are not aware of any possible removal of this option. I just found out because I set up a new computer recently and couldn't find the option in the UI.

> [...] to prevent vte from rendering the already bold
> font even bolder.

This synthesized, faux-bold has recently been removed in the vte 0.53 (gnome-terminal 3.29) development series. That is, independently of the allow-bold setting, you won't get an even bolder text; you'll get the same font if it's bold to begin with. (The same story for italic, as it's always been: if your base font is italic then the italic attribute doesn't have any additional visual effect.)

I'm wondering, similarly to how we only offer monospace fonts, maybe should we only offer regular (non-bold non-italic) fonts?

May I kindly ask: Why do you use a bold font at the first place? Whatever your reason is (e.g. better visibility), doesn't that apply to webpages you visit, documents you view, etc., and also the desktop's overall interface (including gnome-terminal's menus, preferences dialogs) etc.? Do you solve this issue there as well; if so, how? I'd like to understand the rationale behind such uncommon configurations.

> [...] at least provide a different option to set the bold (and maybe
> italic) font variant separately, so users can find a different solution.

I'm almost certain that you can do this by configuring fontconfig (and then that could apply to the rest of the apps, or at least to a significant portion of them, as per my previous question), although I haven't studied the details.

> Also this change is rather sneaky, as users who enabled it already won't
> notice anything for now and are not aware of any possible removal of this
> option. I just found out because I set up a new computer recently and
> couldn't find the option in the UI.

I'm not sure what we should've done here differently (without somewhat further overcomplicating something that we're in the process of simplifying).

(In reply to Egmont Koblinger from comment #19)
> > [...] to prevent vte from rendering the already bold
> > font even bolder.
> 
> This synthesized, faux-bold has recently been removed in the vte 0.53
> (gnome-terminal 3.29) development series. That is, independently of the
> allow-bold setting, you won't get an even bolder text; you'll get the same
> font if it's bold to begin with. (The same story for italic, as it's always
> been: if your base font is italic then the italic attribute doesn't have any
> additional visual effect.)

This sounds like it should be the desired behaviour and provide a solution (at least for my part). Is there a way to test this out in a GNOME 3.28 environment? I assume jhbuild would be the way to go though I've never used that. Is it possible to compile only vte and gnome-terminal from source and test it that way? (Maybe we could talk about this via IRC at #vte as it is not in the scope of this bug report?)

> May I kindly ask: Why do you use a bold font at the first place? Whatever
> your reason is (e.g. better visibility), doesn't that apply to webpages you
> visit, documents you view, etc., and also the desktop's overall interface
> (including gnome-terminal's menus, preferences dialogs) etc.? Do you solve
> this issue there as well; if so, how? I'd like to understand the rationale
> behind such uncommon configurations.

Yes, the reason is mainly visibility as well as esthetics and ergonomics. See the screenshot attached for an example of my terminal configuration with bold and normal font variants in comparison. I do not change other fonts to bold (documents, default UI text, etc.) as the terminal is my (only) main application using a dark colorscheme. Bold and medium bold text on a dark background looks "brighter" and more "visible" to me without making it an overly "burning" experience (that is using just plain white text on a black background).

> > Also this change is rather sneaky, as users who enabled it already won't
> > notice anything for now and are not aware of any possible removal of this
> > option. I just found out because I set up a new computer recently and
> > couldn't find the option in the UI.
> 
> I'm not sure what we should've done here differently (without somewhat
> further overcomplicating something that we're in the process of simplifying).
From a developer's point of view I agree with you, it's just that normal users with no code knowledge only see a feature being removed and consequently get angry/confused about it. I am sorry if I sounded like that, also because I do not have an actual idea what to do differently here. It certainly helps though that you waited for feedback. :)

Created attachment 371887 [details]
Comparison between non-bold and bold font variants in gnome-terminal 3.28.0

The regular font variant (top) looks a bit dim, whereas the bold one (bottom) has good visibility and doesn't suffer that much from rasterization due to the display's resolution.

(In reply to Martin Schwan from comment #20)

> Is it possible to compile only vte and gnome-terminal from source and
> test it that way?

Yup I think that's what you should do (vte only). I'm not a jhbuild guy either. Current git HEAD is officially unstable, in practice pretty stable right now, you're good to go with it. Replace the system libs (or fiddle with LD_PRELOAD or LD_LIBRARY_PATH, although I'm not sure how that does along with dbus/systemd launching), and quit all gnome-terminal windows at once. If broken big time, fix from an xterm :)

> Yes, the reason is mainly visibility as well as esthetics and ergonomics.

I see (although sure it looks somewhat different on your monitor than on mine). Nice, pleasant color scheme and indeed the bold looks a bit more readable at first glimpse. But it's more like a subtle personal preference rather than the regular font being problematic, correct?

(In reply to Egmont Koblinger from comment #22)
> (In reply to Martin Schwan from comment #20)
> 
> > Is it possible to compile only vte and gnome-terminal from source and
> > test it that way?
> 
> Yup I think that's what you should do (vte only). I'm not a jhbuild guy
> either. Current git HEAD is officially unstable, in practice pretty stable
> right now, you're good to go with it. Replace the system libs (or fiddle
> with LD_PRELOAD or LD_LIBRARY_PATH, although I'm not sure how that does
> along with dbus/systemd launching), and quit all gnome-terminal windows at
> once. If broken big time, fix from an xterm :)

I compiled vte from source and tested it with the included example application (located in bindings/vala/): Removing faux-bold indeed solves the issue for me and bold fonts render properly now.

> > Yes, the reason is mainly visibility as well as esthetics and ergonomics.
> 
> I see (although sure it looks somewhat different on your monitor than on
> mine). Nice, pleasant color scheme and indeed the bold looks a bit more
> readable at first glimpse. But it's more like a subtle personal preference
> rather than the regular font being problematic, correct?

Well, yes, it's a combination of multiple things: Font hinting, the screen resolution being relatively low compared to the font size (full HD is not enough, hehe...) and anti-aliasing being the main reasons. And of course, personal preference is always an important factor.

(In reply to Arkady Rost from comment #0)

> urxvt supports it with intensiveStyles flag and xterm with +bdc.

Just for future reference: xterm +bdc is something related but different. Our new feature is equivalent to xterm +pc and urxvt +is.

(In reply to Christian Persch from comment #9)

> +        pspecs[PROP_BOLD_IS_BRIGHT] =
> +                g_param_spec_boolean ("bold-is-bright", NULL, NULL,
> +                                      TRUE,
> 
> Can we switch that to FALSE? :-)

I've changed my mind: Let's do so! :-)

I've been using my g-t with "show bold in bright" disabled for quite a while now. Took me a few days to get used to it, but it's absolutely okay. Actually it often improves readability of colored text (I have white background).

Kitty's author also has a firm opinion on this being the right approach, see https://github.com/kovidgoyal/kitty/issues/197.

I agree with him that if a colorscheme developer really wants to have bright then they should use SGR 90-97/100-107, rather than rely on the legacy ambiguous bold/bright (which we'd like to mean bold only) attribute.

Long story short: I've changed my opinion here and I wouldn't mind making "disabled" our new default, to push the world a little bit towards a cleaner future.

(Unlike Kitty, we'd still have this option for a couple of years going.)

Okay for 0-55 / 3-31?

We could flip the default in g-t only. Then – obviously – only g-t users would be affected, and they could easily revert to the previous behavior.

Or we could also flip vte's default. That way all the vte-based emulators that haven't added a checkbox for this new feature would suddenly be forced to the new behavior. That is, we'd push this new behavior more aggressively, somewhat breaking existing behavior.

I've filed an FYI against most vte-based apps about the new API half a year ago, and I'm happy to add a followup comment about the default getting flipped, if we decide to go for it.

I think we should change the default in vte *and* g-t.

> I think we should change the default in vte *and* g-t.

Done.

(Still leaving the bug open for allow-bold's deprecation/removal at some later point.)

Created attachment 373913 [details]
linux-menuconfig-bold-as-bright

One thing to note is that disabling the "Show bold text in bright colors" option does cause a visual regression in some legacy ncurses/terminal applications.

As an example, here's the Linux kernel's "menuconfig" screen, which loses its bright window borders. Contrast is a bit of a wash depending on color theme, but with the "Linux console" set as in this screenshot, it's mostly more readable with the bold as bright enabled.

Thanks for the heads-up!

We're aware that the colors in certain apps change, not always to a "more readable" one. We've mentioned some examples, like alsamixer's bright yellow becoming a dull yellow (or, depending on the color scheme, brown).

That being said, separating the "bold" attribute from the colors is something we'd like to push for. We've mentioned earlier in this thread that Kitty (a new terminal emulator that's apparently quite popular among power users, hence its user base probably has a correlation with those who compile the kernel) also clearly separates the bold attribute from the color, and unlike us, doesn't even have an option to switch to the legacy behavior. xterm and urxvt also have options to behave like our new default (mentioned here earlier), although that's not their default.

"menuconfig" is written using the ncurses library. Reading its source reveals that it uses only 8 colors, and sometimes combines them with the A_BOLD flag. One might argue that A_BOLD means "bold and/or bright" and it's expected that the color becomes bright, but this is exactly the legacy craziness we're deprecating. To demonstrate how broken the old/current situation is, look at this in scripts/kconfig/lxdialog/util.c:

  DLG_COLOR(border, COLOR_WHITE, COLOR_WHITE, true);

The dialog border is set to "white on white", or rather, "light gray on light gray" (so ncurses's naming of the color is already pretty unfortunate), which, due to the "bold" flag, is supposed to render as "white on light gray". That is, menuconfig explicitly assumes (incorrectly) that the terminal emulator is going to interpret the legacy ambiguous "bold/bright" flag, the one called by ncurses "A_BOLD", as at least "bright" (maybe "bold" too). And sets the same color for fg and bg and expects that to be visible. Isn't this crazy?

If the intent of menuconfig is to make these bright, it should pick the _colors_ accordingly. That is, if 16 or 256 color support is detected (which is nowadays supported and reported by almost all graphical terminal emulators), it should pick indices 8..15 for the bright colors, instead of or in addition to the bold flag.

I sincerely hope that someone will volunteer to fix this in menuconfig, and that the kernel developers would accept that patch. Kitty's author has successfully convinced a few other apps to switch to the proper 16 colors rather than 8 + the terrible bold/bright hack. (Could you perhaps work on this, or at least notify them? Thanks a lot in advance!)

"MENUCONFIG_COLOR=blackbg make menuconfig" is even worse, the bottom row's _text_ is mostly invisible (black on black).

Let me add that ECMA-48 §8.3.117 says SGR 1 (which ncurses's A_BOLD maps to) is "bold or increased intensity". This clarifies that VTE's new default behavior does conform to the standard, and thus clarifies that "make menuconfig" is indeed making a wrong assumption.

Alright, yes, menuconfig can (and probably should be) changed - as long as those changes don't make it worse on the Linux framebuffer console (which doesn't implement 16 color support, and implements bold by increasing intensity).

I guess my point was that there is a lot of existing software out there, sometimes which can't be changed, or is on a different machine accessed via ssh/telnet/whatever, doesn't have modern terminfo, etc. It makes sense to at a minimum leave the option of "bold is bright" available as a compatibility setting.

Indeed, in gnome-terminal, maybe it should be moved to the "Compatibility" tab at the same time as the switch to having the setting off by default?

> as long as those changes don't make it worse on the Linux framebuffer console

Definitely! (Which is bad news for them, they'd have to somehow have slightly different logic for 8-color and 16+-color terminals.)

(Does really not even the _framebuffer_ support 16 colors? I thought it did (maybe even 256), 8 was just a limitation of VGA modes. I might easily be wrong here. And, of course, as long as the "linux" terminfo description says it's 8 colors only, it wouldn't help us if framebuffer supported more.)

> It makes sense to at a minimum leave the option of "bold is bright" available
> as a compatibility setting.

I'd definitely wish to leave it there for at least a couple of years. First, once this default's flip goes out, we'll probably get precious feedback on how it went (at least the amount of people who complain would be a good sign). Then, a few years from now, when we're about to deprecate it, probably it'll be made a hidden setting for a while. Then again, the number of people looking for this option would be a good feedback whether we can move forward and remove it. And then it'd be again maybe a year or two until the removal. In the mean time, developers of menuconfig or other similar apps will hopefully start adjusting their software.

> maybe it should be moved to the "Compatibility" tab

On one hand sure it's a compability thing (and there's more room on that tab), on the other hand we have everything related to colors on a single tab now. I'm really not sure. I'm tempted to be lazy here and just leave it as-is.

(In reply to Egmont Koblinger from comment #33)
> (Does really not even the _framebuffer_ support 16 colors? I thought it did
> (maybe even 256), 8 was just a limitation of VGA modes. I might easily be
> wrong here. And, of course, as long as the "linux" terminfo description says
> it's 8 colors only, it wouldn't help us if framebuffer supported more.)

The Linux framebuffer and VGA text console display 16 colors, but they only implement the escape sequences to access 8 colors. The only way to access the high-intensity variants is to use the "bold" mode (which means you can only use them as foreground colors).

(In reply to Calvin Walton from comment #34)
> (In reply to Egmont Koblinger from comment #33)
> > (Does really not even the _framebuffer_ support 16 colors? I thought it did
> > (maybe even 256), 8 was just a limitation of VGA modes. I might easily be
> > wrong here. And, of course, as long as the "linux" terminfo description says
> > it's 8 colors only, it wouldn't help us if framebuffer supported more.)
> 
> The Linux framebuffer and VGA text console display 16 colors, but they only
> implement the escape sequences to access 8 colors. The only way to access
> the high-intensity variants is to use the "bold" mode (which means you can
> only use them as foreground colors).

Ah, never mind, I got this wrong. The linux fb console can select the high intensity foreground colors using the color escapes, \e[90m through \e[97m without using the bold attribute. This isn't a problem after all! Sorry for the errors earlier.

The high intensity background colors are not selectable at all, however.

I can't believe how quickly time flies. It was almost 2 years ago that we demoted "allow-bold" to a hidden g-t preference, and 1.5 years ago that it was released as stable.

We hardly got any feedback/complaints about it, if at all – apart from comments 18-23 here which as far as I understand were addressed by the removal of faux bold.

There are still two independent pending patches:

- officially deprecate it in vte (including PROP_ALLOW_BOLD, missing from the patch!!!),

- remove the hidden "allow-bold" preference from g-t.

Christian, shall we move forward? I'd be super happy to formally deprecate for 0.60. Maybe we can also already remove the hidden g-t pref?

> - officially deprecate it in vte (including PROP_ALLOW_BOLD, missing from the patch!!!),

Just deprecate, or remove completely (making the API no-op's)?

> - remove the hidden "allow-bold" preference from g-t.

Yes.

> Just deprecate, or remove completely (making the API no-op's)?

I'd just deprecate now, but keep the functionality. I could file an FYI to various terminal apps that use it, so that they can remove the checkbox before the functionality breaks.

Ok, let's do that :-)

Comment on attachment 365278 [details] [review]
Deprecate allow-bold, vte v1

Committed an updated version of this patch.

Comment on attachment 365279 [details] [review]
Remove allow-bold, gnome-terminal v1

Committed an updated version of this patch.

Just for the record:

Alacritty flipped its default today to 'draw_bold_text_with_bright_colors: false'.

See https://github.com/alacritty/alacritty/issues/2779 for details.

It's lovely to see more and more terminals heading in this direction.

(In reply to Egmont Koblinger from comment #36)
> We hardly got any feedback/complaints about it, if at all – apart from
> comments 18-23 here which as far as I understand were addressed by the
> removal of faux bold.

You didn't receive complaints because it still worked (until just now I restarted my gnome-terminal).

Bold text, well, is bold. But I expect them to be brighter (actually I didn't know what terminals supported is bold text; I thought they were intended to be bright colored until things went unexpected and I found the hidden setting). I want brighter colors, not bolder text. I'll try to dig a compatible way, but if you know how to do bright colors the right way, please tell me.

> > We hardly got any feedback/complaints about it [...]
> 
> You didn't receive complaints because it still worked [...]

It's a bit unfortunate, but this bug is actually a collection of a few related issues. The bits you quoted from me referred to demoting the "allow bold" feature (in other words: allowing to completely disable the bold font weight) to a hidden one (and eventually removing it); whereas the rest of your comment is about "bold is bright" (that is: the SGR 1 sequence not only making the text bold but perhaps also brighter). So it's unclear to me which one you're referring to.

The "bold is bright" change received more positive feedback than I anticipated, see https://github.com/alacritty/alacritty/issues/2776#issuecomment-528439444, overall I'm truly happy that we did it.

> I thought they were intended to be bright colored until things went unexpected and I found the hidden setting

The setting to restore this behavior is not hidden, it's available ever since we implemented this feature, at Preferences -> profile -> Colors -> Show bold text in bright colors.

> if you know how to do bright colors the right way, please tell me.

This was already summarized multiple times in this bug alone, including comments 1, 14, 25, 30.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2285.