easylogging++: Generalize TERM rule for color-supporting terminals #9772
Conversation
laanwj
force-pushed
the
2025-02-tmux-256color
branch
from
53aa757 to
e0dbf91
Compare
laanwj
changed the title
With newer versions of tmux, such as version 3.4 packaged by Ubuntu 24.04, `tmux-256color` is the default TERM variable value. Instead of adding it specifically, extend the rule to look for `-color` or `-256color` in TERM, as these can all be assumed to support color.
laanwj
force-pushed
the
2025-02-tmux-256color
branch
from
e0dbf91 to
d588a99
Compare
|
Okay, implemented the string search instead. Another alternative would be to use a blacklist instead of a whitelist. All modern terminals can at least parse basic ANSI 16-color sequences, although some might ignore them for aesthetic reasons. Exceptions would be TERM empty or non-existent (eg as on Windows), |
| || term == "screen" || term == "linux" || term == "cygwin" | ||
| || term == "screen-256color" || term == "screen.xterm-256color"; | ||
| return term == "xterm" || term == "screen" || term == "linux" || term == "cygwin" | ||
| || term.find("-color") != std::string::npos |
There was a problem hiding this comment.
I'm OK with this choice, though I was expecting just a check for the ending (sadly, ends_with requires c++20, but an equivalent is trivial using compare).
There was a problem hiding this comment.
Do you think that really matters for the heuristic if it's at the end? What if it's tmux-color-graphics or whatever.
There was a problem hiding this comment.
Possible variants of -(256)?color are why I'm OK with the choice. However, when inferring a rule from a pattern, I think it helps to do so as narrowly as possible: This code has existed for a long time, and, in all that time, -color-x has never arisen, whereas -color and -256color have. So, the narrow choice clarifies to the reader (including the compiler, and therefore the machine which runs the code): I know exactly where this should occur in the string. Furthermore, much like browser version strings which "look like" (i.e. match widely used patterns for) prior browsers, it seems positioning color as a suffix has a clear intent behind it, so if someone wanted to add another component to the string, they'd do it in the middle. If I'm wrong, and a color terminal adds -color in the middle, then it'd probably better to deal with that case with real data available, so as to once again suitably narrow the pattern. In fact, the main worry I have about looking for -color anywhere in the string mirrors your question: What if the word color appears mid-string and it isn't a color terminal, because color is part of a larger word? For example, tmux-colorless. Then, you'd have two problems, because someone responding to that bug report would have to alter the algorithm, and not break anything else, which, based on just the code, without knowledge of the history, would involve either an explicit exclusion of the new value, or some other complication of the rule. I considered this scenario a low risk, but it illustrates the broader principle.
|
i think i don't care enough about this to keep it open, i thought it'd be useful but it's turning into too much arguing. |
With newer versions of tmux, such as version 3.4 packaged by Ubuntu 24.04,
tmux-256colorthe default TERM variable value.Instead of adding it specifically, extend the rule to look for
-coloror-256colorin TERM, as these can all be assumed to support color.