Tree-view child process username not visible

[nodesocket]

When using tree-view the username for child processes color is black and thus not visible (background is also black), unless you've actively selected the child process row. See attached screenshot.

[hishamhm]

This is an issue in your terminal color configuration. It should be gray.

To confirm that it is the case, paste the following in your terminal:

echo -e '\033[1;31m I am red! \033[1;32m I am green! \033[1;30m I am gray! \033[0m'

If you only see I am red! I am green! then it's an issue with your terminal; historically \033[1;30m has always been gray.

What is your distro and what terminal are you using? This seems to be a common complaint lately.

[nodesocket]

Hummm, don't see I am gray.

Running CentOS 6.5 with zsh and oh-my-zsh (https://github.com/robbyrussell/oh-my-zsh).

[hishamhm]

On what terminal? gnome-terminal on Gnome? Konsole on KDE? xfce-terminal? xterm? rxvt?

[nodesocket]

xterm

[hishamhm]

Use the "Broken Gray" color scheme now available in htop 2.0. :)
Cheers!

[kovidgoyal]

\033[1;30m is not historically always gray. In fact it is never gray. 1; 30 means:

1 - Bold or increased intensity
30 - Foreground color 0

See section on SGR parameters here: https://en.wikipedia.org/wiki/ANSI_escape_code#CSI_codes

Some terminals choose to implement 1 as bold, some as increased intensity, and some as both. Some have options to toggle implementing 1 as increased intensity+bold or only bold. Increased intensity is typically implemented by mapping the basic colors 30-37 to 90-97 and 40-47 to 100-107

Foreground color 0 is often black which is why the higher intensity version of it is often gray. However, most terminals allow users to redefine the 16 ANSI colors to be whatever they want. Examples of such terminals: konsole, xterm, termite, kitty, any libvte based terminal.

IMO htop should not be relying on 0+1 = gray which works only if the terminal in question happens to interpret 1 as increased intensity or increased intensity and bold. Instead use
\033[90m

I assume that what you are trying to accomplish is make the "gray text" seem "less important". If so, the marking it as bold/high intensity is the incorrect way to do it, since bold/high intensity means "more important" not "less important".

Of course, if you ask me you should just be using true color support directly since all modern terminals implement it. Then you can specify colors exactly and not be at the mercy of how the user happens to have redefined the 16 colors. Or if that is too radical, at least use 256 colors. Then you can refer to this chart: https://upload.wikimedia.org/wikipedia/en/1/15/Xterm_256color_chart.svg to get your colors. Although, at least in XTerm all 246 colors can be redefined by the user.

[kovidgoyal]

Oh and I should add that historically, for actual hardware terminals, 1 was just bold not high intensity -- interpreting it as high intensity is just a kludge that software terminal emulators used to use when they did not support bold fonts. http://www.vt100.net/docs/vt510-rm/SGR.html

[hishamhm]

@kovidgoyal Thanks for the comment! I am aware of the history of ANSI color codes (though this is a great recap). I expressed myself badly when I said "historically", because my concern with the historical meaning of color codes is in the context of Linux, which is what htop was originally designed for, and not old-time hardware Unix terminals.

Of course, if you ask me you should just be using true color support directly since all modern terminals implement it. Then you can specify colors exactly and not be at the mercy of how the user happens to have redefined the 16 colors. Or if that is too radical, at least use 256 colors. Then you can refer to this chart: https://upload.wikimedia.org/wikipedia/en/1/15/Xterm_256color_chart.svg to get your colors. Although, at least in XTerm all 246 colors can be redefined by the user.

I agree. That is the right way to go in the long run, but I can't work on adding this right now. It's definitely something I want to do in the future (or accept a pull request for, if somebody beats me to it :) ).

[kovidgoyal]

My concern is mostly that htop does not work out of the box with terminals that choose to implement 1 as proper bold instead of high intensity. Since it is desirable to be able to set bold independently of the color, it would be good if htop stopped conflating the two, otherwise it just leads to unnecessary bug report noise both for htop and for terminal emulators that do the right thing with bold. Changing \033[1;30m to \033[90m will fix this with, as far as I can see, no drawbacks. And no need for large/invasive changes to the codebase, such as adding support for truecolor.

[hishamhm]

@kovidgoyal htop does not emit escape codes itself; it uses ncurses color pairs. :\

[kovidgoyal]

You have my sympathies, curses is a truly awful library :) But IIRC you can use the aixterm colors (colors from 8 to 15) in curses as well. Color number 8 init_color()/color_pair() will correspond to 90. See this test script:

from curses import wrapper, start_color, use_default_colors, init_pair, color_pair
import curses
def main(stdscr):
    start_color()
    use_default_colors()
    for i in range(0, curses.COLORS):
        init_pair(i + 1, i, -1)
        stdscr.addstr(str(i) + ' ', color_pair(i+1))
    stdscr.getch()
wrapper(main)

When i = 8 it will correspond to SGR 90 which is gray on most terminals
You just have to be careful to check that the number of colors (curses.COLORS is >= 8) if it is not then fallbak to using the old way.

[jtrmal]

I can confirm this is an issue in iterm2 in MacOS X. The aforementioned reason led to instant solution: both "Draw bold text in bold font" and "Draw bold text in bright colors" options have to be checked.
It is my understanding it's not really fault of htop, but let me say this (and lot of other terminal-related rendering issues) a very difficult problem to figure out for people maybe proficient in unix/linux but not having the HW terminal experience.

[TheJJ]

@hishamhm any chance that the htop default scheme is updated to be visible properly?