After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 792501 - "Bold color" ignored when "bold is bright" is off
"Bold color" ignored when "bold is bright" is off
Status: RESOLVED FIXED
Product: gnome-terminal
Classification: Core
Component: general
git master
Other Linux
: Normal minor
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-01-13 19:04 UTC by Egmont Koblinger
Modified: 2018-01-13 23:13 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Egmont Koblinger 2018-01-13 19:04:30 UTC
From https://bugzilla.xfce.org/show_bug.cgi?id=14127#c3:

When the new API option "Show bold text in bright colors" is disabled (the new behavior), "Bold color" (the color to use when the _default color_ is turned bold) is ignored.

Depending our philosophy, there's two approaches we could take:

Technically, we could easily keep "Bold color" working in this case too. And if that's the decision then it's a minor VTE change required (move the "&& m_bold_is_bright" condition three lines down to the inner "else" branch).

I'd probably prefer not to restore this behavior, though, as it would go against the intent of the new API, the total separation between boldness and color.

If we decide on keeping the current approach, a followup g-t change should be desirable when the off state of "bold is bright" makes the "bold color" option disabled. And then it's unfortunate that they're in the unnatural order, maybe the new option should be moved up... where exactly? to the very top of the page? Or we'll just revise it with the planned big color scheme refacting...

(The intrinsic problem is: just as "bold is bright" is a legacy compatibility feature, "bold color" is also one and IMHO ideally it shouldn't exist.)
Comment 1 Igor 2018-01-13 19:22:10 UTC
Egmont, I'd suggest that "bold color" and "bold is bright" do not depend on each other. As you're saying, the new intention is to decouple boldness from color.
Can we keep "bold color" setting, but independently from "bold is bright"? So the latter would affect custom colored bold text, while "bold color" would allow to override default bold text color.
Comment 2 Egmont Koblinger 2018-01-13 20:04:19 UTC
It's not the "philosophy" I'd like to go for, however, clearly makes our code and UIs simpler and more logical, and users who wish to (e.g. Solarized fans) can easily disable both features.

The entire set of APIs might get redesigned soon, and then we can get back to this question. Until then, we can take the easy path.

I'll wait for Christian to speak up if he objects, otherwise I'll submit the vte change I've described above in a few days.
Comment 3 Christian Persch 2018-01-13 21:22:46 UTC
(In reply to Egmont Koblinger from comment #0)
> I'd probably prefer not to restore this behavior, though, as it would go
> against the intent of the new API, the total separation between boldness and
> color.

I'm ok with that.
 
> If we decide on keeping the current approach, a followup g-t change should
> be desirable when the off state of "bold is bright" makes the "bold color"
> option disabled. And then it's unfortunate that they're in the unnatural
> order, maybe the new option should be moved up... where exactly? to the very
> top of the page? Or we'll just revise it with the planned big color scheme
> refacting...
> 
> (The intrinsic problem is: just as "bold is bright" is a legacy
> compatibility feature, "bold color" is also one and IMHO ideally it
> shouldn't exist.)

Yes. Do we want to apply the same to special colours for other attributes too, e.g. the proposed underline colour (bug 104968) and reverse colours (307073); i.e. WONTFIX those other bugs?
Comment 4 Egmont Koblinger 2018-01-13 22:12:32 UTC
> > I'd probably prefer not to restore this behavior, though, as it would go
> > against the intent of the new API, the total separation between boldness and
> > color.
> 
> I'm ok with that.

Er, the thing is, in comment 2 I changed my mind to take the simpler approach, as suggested by Igor. Are you okay with _that_, too? :-)

> Yes. Do we want to apply the same to special colours for other attributes
> too, e.g. the proposed underline colour (bug 104968) and reverse colours
> (307073); i.e. WONTFIX those other bugs?

I'd personally close as WONTFIX, and eventually (in a couple of years) probably deprecate "bold color" too.

(Regarding "reverse colours", the funny thing is that according to ECMA-48 or T-416, SGR 7 is actually "negative image", which I believe should be (255-r, 255-g, 255-b) individually for both fg and bg. It would be cool to know whether any device ever implemented it like this, or everyone went for "reverse" aka "inverse video" instead. Or just these docs use terribly sloppy wording? :-))
Comment 5 Christian Persch 2018-01-13 22:36:03 UTC
(In reply to Egmont Koblinger from comment #4)
> > > I'd probably prefer not to restore this behavior, though, as it would go
> > > against the intent of the new API, the total separation between boldness and
> > > color.
> > 
> > I'm ok with that.
> 
> Er, the thing is, in comment 2 I changed my mind to take the simpler
> approach, as suggested by Igor. Are you okay with _that_, too? :-)

I'm ok with either, and the simpler approach is easier to understand for the user, so let's go with that.

> > Yes. Do we want to apply the same to special colours for other attributes
> > too, e.g. the proposed underline colour (bug 104968) and reverse colours
> > (307073); i.e. WONTFIX those other bugs?
> 
> I'd personally close as WONTFIX, and eventually (in a couple of years)
> probably deprecate "bold color" too.

I'll WONTFIX them then, and with the palette work next cycle we can at least deprecate the bold colour?

> (Regarding "reverse colours", the funny thing is that according to ECMA-48
> or T-416, SGR 7 is actually "negative image", which I believe should be
> (255-r, 255-g, 255-b) individually for both fg and bg. It would be cool to
> know whether any device ever implemented it like this, or everyone went for
> "reverse" aka "inverse video" instead. Or just these docs use terribly
> sloppy wording? :-))

I'm pretty sure it was always implemented as swapping fore and back; this originated on monochrome terminals where that's all you can do.  It would be a fun experiment to try the actual 'negative' effect, but I think it'll probably look weird :-)
Comment 6 Christian Persch 2018-01-13 22:45:36 UTC
Just tried it, and actually, it doesn't look /that/ odd!
Comment 7 Egmont Koblinger 2018-01-13 22:50:53 UTC
My guess for the mouse highlighting experience is that it'd be terrible... I'm yet to try :)
Comment 8 Egmont Koblinger 2018-01-13 23:13:20 UTC
Fixed.