On 12/13/2016 10:25 AM, ambrus wrote:
Terminal emulators handle bold in a thousand different ways. Many
terminal emulators, including xterm and rxvt, have settings for this.
The default behaviour might differ. (Mintty does too, but the
settings are also broken.)
I have noticed that. st, for example, follows pretty much the same
approach as urxvt. Which makes sense because it's the simplest.
I have digged further into the matter and found out the reason of the
different behavior. xterm is conscious if the color was set in "hicolor"
mode, that is, using extended foreground escape sequence. It keeps track
of that somehow, you can tell if you paste this printf:
$ printf "\033[1;38;5;2mNot bright \033[32mBright\033[0m"
urxvt does not do that. I have checked the process_sgr_mode method and
it does not seem to particularilly separate the two modes (besides of
course the parsing of the escape sequences), that's why it is bright in
both cases.
For curiosity's sake, I hacked the code in order to keep track whether
the color was set via the regular foreground color sequence or the
extended foreground color sequence. I managed to make it work, and now
the terminal happily behaved like xterm with the above printf.
Then I found out that with the patch htop was not displaying its default
theme properly. In particular, it seemed that the bold gray would be
rendered as black. After more digging, I realized there was something
missing: I had forgotten about terminfo.
If you check the setaf (and setab) of urxvt you can see that it only
uses the extended format (\E[38;5;%p1%dm) for color codes. htop was
probably querying the terminfo database and obtaining the extended color
sequence, which, of course, it wasn't brightening colors anymore as my
hack disabled bright colors with extended color sequences. In
comparison, the setaf of xterm looks like this:
setaf=\E[
%?
%p1%{8}%<
%t3%p1%d
%e
%p1%{16}%<
%t9%p1%{8}%-%d
%e38;5;
%p1%d
%;
m
Now, I won't comment on the garbled mess that terminfo descriptions are,
but it seems that the terminfo description tries to return the regular
foreground sequence (3#m) if the color is < 8, the bright foreground
sequence (9#m) if it is < 16, and finally the extended foreground
sequence (38;5;#m) for the other cases. If that was the case, if I
modified the terminfo entry to match xterm, it would fix the problem
with htop. My theory was correct, in fact, when I forced the terminal
type to xterm-256color via environment variable, htop would display the
colors correctly.
But you probably all know that. Why am I writing this then? No reason
besides the fact that if someone reads up the list archive, they will
not find an unanswered question (:
Marco
_______________________________________________
rxvt-unicode mailing list
[email protected]
http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
