mc displayes differently directories in face of xterm-256color

[covex]

Please see the ​https://bugzilla.redhat.com/show_bug.cgi?id=911497 for details.

[egmont]

With TERM=xterm-256color you get 256 (actually a bit less than that, maybe 240-ish) different colors, plus you get a bold attribute that is totally independent of the color. That is, you can get any of them in either normal or bold, and this changes the boldness only, not the color.

With the legacy TERM=xterm color palette the story is more complicated. You have 8 basic colors, plus there's 1 flag which is sometimes interpreted as "bold" (not sure if there's any actual terminal doing this), sometimes as "bright" (for foreground color only - e.g. on Linux console due to lack of bold support), and sometimes (probably this is the most typical in graphical terminals) as "bold+bright". This depends on your terminal, you might be able to configure it to some extent (e.g. gnome-terminal easily lets you disable bold), but the application has no way of telling how the terminal handles it. Usually there's no real "white" among the 8 basic colors, only "lightgray". To get "white" your best bet is "lightgray" with the "bold and/or bright" flag (which is called "white" in mc's skin files), which may end up as "bold lightgray", "normal white", or "bold white", depending on your terminal.

I'm afraid noone knows what was the original intent with directories (how the skin would look like if 16 distinct colors and a separate boldness existed at that time - would they be bold lightgray, normal white, or bold white). They probably just wanted them to stand out, and this confused bold/bright attribute was the only way to go.

What you could do is to add the "bold" attributes to all the colors in the skin file that are of the bright type. E.g. change "directory=white;" to "directory=white;;bold", and so on. This would modify the skin under TERM=xterm-256color to match the look of TERM=xterm, provided that your terminal actually goes bold for legacy bright colors (or it never goes bold) - I think this covers most of the widely used terminals.

There are two questions: 1. Does the skin with bold directories (and all other bright colors being bold) look better than the non-bold versions? 2. Is it important to have the same look with different TERM variables? If the answer is "yes" to either one then go for the change outlined above, for the "default" and probably some other old skins - just please don't touch the skins that were designed with 256 colors in mind. :)

[egmont]

default skin modified to be bold where bright

[egmont]

I've added a modified version of the default skin to be bold wherever bright. Covex, could you please try this skin (mc -S default_bold.ini, or replace your default.ini with this file) and tell us whether it works for you as you'd expect?

[egmont]

Please also see ticket #3050.

[egmont]

Another idea is: instead of changing the skin definition files, we could change the skin parsing code. In the absence of "256colors=true" in the config, it could refuse any color that's out of the 16-color palette (including bright as background colors), and it could also ignore the "bold" attribute and apply it automatically for bright colors. This would prevent such discrepancies from appearing in the configs.

[zaytsev]

I hit the same problem, but then discovered, that if you *don't* do any overrides in tmux and start it with "TERM=screen-256color tmux", then mc inside will just work as it should =) all with bold colors, yay!

[covex]

Starting mc with mc -S default_bold.ini

┌──────────────── Warning ────────────────┐
│ │
│ Unable to load 'default_bold.ini' skin. │
│ Default skin has been loaded │
│ │
└─────────────────────────────────────────┘

Replacing this default.ini skin works then. I am not sure what is the proper solution, or whether this is really a bug or feature. Anyway using this default_bold.ini is fine for me. I've checked the #3050 but it is not obious to me what fix was used there.

[egmont]

Let me correct my comment 1. The story is even more complicated.

Originally there were 8 colors only (fg: SGR 30..37, bg: SGR 40..47), plus a "bold/bright" flag which often made the foreground have a different (brighter) color.

Then it was extended by the 8 brighter colors having their own color codes (fg: SGR 90..97, bg: SGR 100..107), to give a palette of 16 different colors, each of which can appear both as foreground or as background. The problem is that due to the stupid ambiguous "bold/bright" flags, in most terminal you can't render foreground colors 0..7 in bold (since turning on boldness also shifts them to colors 8..15). You can have colors 0..7 in normal weight, and colors 8..15 as either normal weight or bold. Interstingly, there's no corresponding TERM=xterm-16color terminfo entry.

Then came 256 colors with 256 brandnew escape code positions (fg: SGR 38;5;0..255, bg: SGR 48;5;0..255). The first 16 of these 256 are the same colors as the legacy 16, except that turning them bold does not make them bright. E.g. while SGR 1;34 becomes color 12 in bold (instead of color 4), SGR 1;38;5;4 is actually color 4 in bold.

So, for colors 8..15 the legacy escape sequences and the 256-color escape sequences do exactly the same, but for colors 0..7 it's not the case. You only have 256 distinct colors, yet, 264 possible ways to choose a color which behave differently (if combined with boldness).

Libraries like ncurses and slang don't expose the possibility to choose from 264 "colors", they only allow 256. How they are converted to SGR codes depend on the terminfo entry. For me, with TERM=xterm-256color, the commands "tput setaf" give this: (and "tput setab" something very similar)

\e[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m

This basically encodes: "if color code < 8 then output SGR 30..37, else if color code < 16 then output SGR 90..97, else output SGR 38;5;16..255".

So, even though terminal emulators [hopefully all of the 256-color aware ones, but who knows for sure...] do support colors 0..7 in bold (using SGR 1;38;5;0..7), you can't access these via ncurses/slang. This way it's backward compatible with the 8/16 color world (an app unaware of 256 colors doesn't look different with TERM=xterm vs. TERM=xterm-256color), but carries its legacy crap.

(Another terminfo definition _could_ simply just say "output SGR 38;5;0..255" for any of the 0..255 colors, in that case colors 0..7 would not go bright when bold. That would make the color and the boldness completely independent from each other, but would alter the look of an 8/16 color app when you switch from TERM=foo to TERM=foo-256color.)

---

Then, on top of it comes whatever mc does when parsing these colors. Before having 256 colors, mc had 16 different color names. That is, it was thinking "the other way around". Instead of saying "bold magenta" in the config file (leaving it a side effect that it might have appeared in a brighter color too), it had "bright magenta" in the config, and in turn asked the terminal to go bold because that's how you get the bright variant.

With the introduction of 256 color, changing this approach would have changed the look of old skins (or the skins would have needed to be adjusted) and would have broken custom skins of users. However, with the (mostly) proper distinction of bold in 256 color world, plus the additional new attributes (underlined etc.) it was desired to separate out this flag.

As a result, mc parses/handles 8/16 color and 256 color skins differently. In 8/16 color mode, upon seeing "brightmagenta" it asks for plain magenta with bold flag. In 256 color mode, it asks for the brightmagenta color without the bold flag. As far as I remember, at least. Yup, it sucks.

---

What would be a good solution? I'm really not sure. I'll think about it.

[andrew_b]

Ticket #3626 has been marked as a duplicate of this ticket.

[broly]

TERM=xterm

[broly]

TERM=xterm-256color

[broly]

hi,

i too have this issue.

here is a picture of the xterm-256color shell, versus TERM=xterm mc:

i'm using a Mac with the Serial program. however i am not sure if that's causing issues. the "worst" issue i've seen with this TERM variable is that some escape characters aren't being handled, but i am working on fixing the PS1 variable. it is currently defined as

PS1=\[\033[01;31m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$

i have also contacted the serial program developer just in case it is related to escape sequences. i find it strange this seems to effect the "padding" characters that homogenise the "dead" (non-navigable) parts of the screen (whether this padding occurs in the directory contents having fewer entries [lines] than the number of available rows, or in the panels of prompts)

[broly]

panel rendering in xterm mode

[broly]

mc_TERM_xterm256color_panel

[egmont]

This bug here is about colors and boldness slightly differing between the two terminal settings (as the directory .ssh is bold+bright in your first screenshot but bright only in the second), but mc being perfectly usable in the mean time. I guess that's not what you're talking about.

Your 256-color layout is utterly broken, and that's a totally different story.

I'm pretty sure it's related to the REP terminal feature which has recently been added to the xterm-256color definition (although I _guess_ it was added to xterm too, but I'm not sure), and apparently your terminal emulator doesn't support it.

See e.g. ​https://gitlab.com/gnachman/iterm2/issues/6249 and follow the links posted there.

[broly]

hello,

just wanted to share that the problem has gone away. i am not sure if updating bash or patching ncurses did the trick, but it's gone now.

you are probably right as to the root of the issue, but i'm just happy it works.

[andrew_b]

Replying to broly:

hello,

just wanted to share that the problem has gone away.

Thanks for the report!

Closed.

[zaytsev]

I have written a script to make the (default) skin look the same in TERM=xterm and TERM=xterm-256 by boldening the bright colors. Now sure what to make of it...

• Shall we change the default skin, so that it is always consistent including with the old days?
• Shall we process more skins with this script? mc-4.6 ?

Files attached.

[zaytsev]

One more comment: of course, the same problem applies to the syntax files, but I think that it's insane to process them. Either this should be done in the mc engine, of not at all. In this case, I think rather not at all. With the skin, I'm not sure.

[egmont]

I have not re-read the discussion of 11-7 years ago. Whatever was written there may not be relevant anymore, and my opinion also might have changed.

---

I've tried 13+2 essentially different terminals (that is, VTE-based ones count as one) that I have installed now. The +2 special ones refer to the multiplexers.

The only one of these that only support 8/16 colors is the Linux console.

All the graphical ones and the multiplexers support 256 or more colors. These are: alacritty, foot, kitty, konsole, mlterm(*), pterm/putty, st, terminology, urxvt, vte, xterm, zutty; screen, tmux.

(*) I've had a bit of a problem with mlterm since, for me, by default it sets TERM=mlterm which claims 8 colors only. But the terminal does support 256 colors, and by setting TERM=mlterm-256color they become accessible.

Yet another honorable mention that I did not include in the count: the long-abandoned eterm which doesn't support UTF-8(!) supports 256 colors.

The list also continues with non-Linux terminals like the default mac terminal, iTerm2, or Windows Terminal.

There have been plenty of brand new terminals appearing in the last decade, many of which I don't have installed, or have never tried. I have good faith in them: for any new player, 256 colors is the absolute minimum, but they probably aim directly for truecolors.

---

I'd conclude that by now terminals that only support 8/16 colors are extremely rare.

A notable exception is the Linux console, a firefighting tool rather than a terminal suitable for productive everyday use. There, due to the lack of bold support, the currently discussed change is a no-op; there the behavior is to use bright color but not bold text.

---

With these in mind, I guess the next question is:

What is more important? Having a consistent look across 16 vs. 256 color terminals; or having a look that looks great on 256 colors, with whatever fallback look that happens to arise on 16 colors?

I'd say the latter. We should focus on 256 color terminals, and make mc's basic skins look as good as we can.

My personal opinion is that both a brighter color and a bolder typeface together are too much, in order to emphasize some text (e.g. directories) one of these is enough. It so happens that this is our current behavior (bright only), and has been ever since 256 color support was added (v4.8.0, 2011) and since users' favorite terminal emulators gradually upgraded to support 256 colors and also report so.

The current behavior (bright only) has been the default behavior for the vast majority of our users, I think it's a great behavior, and users don't seem to complain either.

Also, interestingly, probably the most notable remaining 16-color terminal, i.e. the Linux console also exhibits this behavior. If we're looking for consistency, this might be at least as important as consistency with 16-color graphical emulators.

So, I personally wouldn't change our default skins now. They are great. Emphasized text is emphasized but not overemphasized. People were gradually switched to and got used to this behavior throughout the last 14 years, with negligible amount of complaints. It's consistent with the Linux console. It's not consistent with graphical 8/16 color terminals which are mostly extinct by today.

[egmont]

One place where I'd perhaps update the skins are the keywords with "bold" in their names, i.e. "helpbold", "editbold", "viewbold".

This would e.g. make the supposedly bold text of manual pages, well, bold.

[egmont]

Yet another possibility to consider: maybe add a new skin file which is the emboldened counterpart of the current default.

[zaytsev]

Hi Egmont, thanks for sharing your take at it!

I used my local mc with the boldened skin for a couple of days, and I'm afraid you are right. With the proper 256 color support it seems too bold and too bright to me. The boldened version due to TERM=xterm is darker, and so doesn't stand out in the same way.

So, I guess, what's gone is gone... In any case, my script is archived in this ticket, and the "proper" bold version is attached as well. If someone wants to have it included in the distributions we can do so like you suggested as default-bold.ini.

Always fascinating, this historical research...