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.

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.