GNOME Bugzilla – Bug 735245
Dim colors handled differently than in xterm, xterm makes more sense
Last modified: 2014-08-25 20:40:36 UTC
vte: The dim (a.k.a. half) attribute is mutually exclusive with the bold attribute, setting one automatically clears the other. Only the first 8 colors have dim counterparts (and as said, they can't be rendered in bold). There's a hardwired corresponding_dim_index array, mapping the dim versions of the first 8 colors to other entries of the 256-color palette. This has the weird consequence that e.g. redefining color 90 also redefines the dimmed version of color 5. xterm: The dim and bold attributes are orthogonal. There's no mapping index, the dimmed color is automatically computed from the base RGB color using some hardwired formula, resulting in effectively 512 foreground colors. And of course each of them can be made bold. xterm's behavior is much cleaner and makes much more sense to me. We already have the "half" attribute in the crowded VteCellAttr structure, so this is not an issue. Also, this would make bug 678765 obsolete.
Created attachment 284266 [details] a handy test script
Created attachment 284267 [details] [review] Fix This fixes the problem. Note that an API call is removed because it no longer makes sense. Can I squeeze this change into master before 3.14 now that we break the API anyways? I wouldn't want to deprecate for years :)
Created attachment 284268 [details] [review] Fix
Comment on attachment 284268 [details] [review] Fix Put the test script somewhere in git, too.
(In reply to comment #4) > Put the test script somewhere in git, too. I put it under 'perf' where we have other test scripts too. We should rename or create another directory like 'tests' or so :) Nevermind.