On 2018-12-15 15:50:26 -0500, Thomas Dickey wrote:
> On Fri, Dec 14, 2018 at 05:15:07AM +0100, Vincent Lefevre wrote:
> ...
> > For instance, in xterm, one uses
> >
> > tput bold; tput setaf 3; echo abcdef
> >
> > but in GNOME Terminal, one uses
> >
> > tput setaf 11; echo abcdef
> >
> > I assume that the reason is that xterm just has 8 colors:
>
> You appear to be confused by the difference between the terminal description,
> and the terminal itself. For xterm, depending on your _preference_, you
> could use TERM=xterm, TERM=xterm-16color, TERM=xterm-256color.
Indeed, nowadays most terminals (including xterm) support 256 colors
(but for xterm, that's not the default... Wondering why and whether
users change the default settings).
On 2018-12-15 09:37:44 -0800, Kevin J. McCarthy wrote:
> Thanks Vincent! I have never looked closely at the reasoning behind the
> current code. I'll take a look at this more closely when I have a chance.
>
> My only comment right now is that we shouldn't change behavior for existing
> xterm/urxvt users. If we can "fix" gnome-terminal without breaking those
> users, I'm fine with adding additional keywords such as "bright" and
> "boldbright".
FYI, I'm using the attached patch, which just changes the behavior
for bright foreground colors: if COLORS >= 16, then it does + 8
instead of using the bold attribute. There are no changes for
terminals configured with fewer than 16 colors, which is the
default for xterm. The possible change of behavior is only when
TERM corresponds to a description with at least 16 colors: one
now just gets a bright color (which is the intent) instead of
bold characters.
Note: With xterm, I set allowBoldFonts to false, so that whatever
method is used, I get bright colors without bold characters.
The issue with bold characters is that when the fonts are small,
such characters may be hard to read (in particular, "m").
If one chooses to support "bold" for terminals with >= 16 colors,
I think that instead of "boldbright", the "bold" prefix would be
sufficient, because when the bold attribute is set, adding 8 or
not to the color number does not seem to produce different results
(I've tested various terminals). In short, one would use:
#colors < 16 >= 16
bright A_BOLD + 8
bold A_BOLD A_BOLD
Another thing, I've just noticed that one should not use the
"bright" prefix for "colorx" with x >= 8. So, the patch is a
bit incorrect (but so is the current code for the background
colors). And "brightdefault" should be incorrect too.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
diff --git a/color.c b/color.c
index af979dfc..628f4874 100644
--- a/color.c
+++ b/color.c
@@ -359,19 +359,19 @@ parse_color_name (const char *s, int *col, int *attr, int
is_fg, BUFFER *err)
if (is_bright)
{
- if (is_fg)
+ if (COLORS >= 16)
{
- *attr |= A_BOLD;
+ /* Advance the color by 8 to get the bright version */
+ *col += 8;
}
- else if (COLORS < 16)
+ else if (is_fg)
{
- /* A_BLINK turns the background color brite on some terms */
- *attr |= A_BLINK;
+ *attr |= A_BOLD;
}
else
{
- /* Advance the color by 8 to get the bright version */
- *col += 8;
+ /* A_BLINK turns the background color brite on some terms */
+ *attr |= A_BLINK;
}
}
