Ticket #3023, #4985: Black and white skin cleanups

[egmontkob]

Proposed changes

Fix & update the black and white skin. Followup internal cleanup.

• Resolves: -b, --nocolor options not working usefully #3023
• Resolves: Remove "SPEC_A_*" colors #4985

Checklist

👉 Our coding style can be found here: https://midnight-commander.org/coding-style/ 👈

• I have referenced the issue(s) resolved by this PR (if any)
• I have signed-off my contribution with git commit --amend -s
• Lint and unit tests pass locally with my changes (make indent && make check)
• I have added tests that prove my fix is effective or that my feature works
• I have added the necessary documentation (if appropriate)

[egmontkob]

The combination of Slang with TERM=xtermm (and no COLORTERM) doesn't work as expected. The error dialog is reversed (although, according to the definitions, it shouldn't), and there's no highlight on the help pages.

As if there was another hardwired skin...?

Weird. Investigating...

[egmontkob]

(Side note: TERM=xterm-mono might be a better choice for testing, since the arrow keys work there.)

No, there isn't another hardwired skin.

With mono TERM values, combined with Slang's color-aware methods, the "bold" flag becomes "reverse" instead. So if either of the properties (or both) are present, you get reverse video, and never bold.

(The same color-aware methods work properly if you pass "default" for both colors, i.e. restrict yourself not to use any colors, however TERM describes a color-aware terminal.)

I suspect this might be a Slang bug, or a pretty unfortunate design decision. Anyway, I've worked it around.

[zyv]

Just tested on AIX (this is built with S-Lang, before all drawing characters were broken):

It's looking better and better, but != signs still remain, no idea why.

[zyv]

Oh, that bugged me last time I worked on AIX. I agree with simplifying stuff. Thank you!

[egmontkob]

Just tested on AIX (this is built with S-Lang, before all drawing characters were broken):

Sorry, I'm really not following this comment.

The screenshot was taken without my patch, as per the commit ID shown. Does my patch change the colors in a notable way (for better or worse)?

By breaking all drawing characters do you mean that at some point real lines were replaced by - + ≠, or did they become even more broken with my patch?

Could you please file a bugreport for the broken lines with the details?

The ACS variant of | is ≠, while - and + stay intact. printf $'\e)0\x0E - + | \e)0\x0F\n' prints - + ≠. Surely this is what happens somewhere, the question is where, why, whose fault is that.

[zyv]

The screenshot was taken without my patch, as per the commit ID shown. Does my patch change the colors in a notable way (for better or worse)?

It is with your patch, and it makes it better. Your changes are in a different repository, and it's hard for me to check them out there. So I rolled the patch up manually. Black and white now makes sense. Before it was still black and white, somehow not consistent.

By breaking all drawing characters do you mean that at some point real lines were replaced by - + ≠, or did they become even more broken with my patch?

Before (not long after 4.8.33), all characters were completely randomly broken. Now, as you can see, the only weird stuff I can notice now is ≠. So the work you did before must have led to these improvements. I'm not sure why ≠ is not replaced.

Could you please file a bugreport for the broken lines with the details?

I'm not sure what I should put in the report. If you log into cfarm119 and run mc, you should see what I see. The source is in ~src/mc.

[egmontkob]

If you log into cfarm119 and run mc

Yup, I see this. The printed escape sequence is somewhat different, equivalent to printf '\e(0 - + | \e(B', but essentially the same story.

I'm not sure what I should put in the report.

Whatever we already know about the story, plus the screenshot :)

By the way, did you tamper with mc's config in some way? In my opinion, the first question is not why there are ≠ symbols instead of |. the first question is why doesn't mc fully shine in colors and proper line drawing chars; do you happen to know this?

xterm, xterm-256color and even xterm-direct256 terminfos seem to be properly installed. TERM=xterm infocmp -a produces essentially the same output as on Linux, the only functional difference is kbs=^H vs. kbs=^? which is irrelevant.

Maybe slang wasn't built with color support or cannot locate the terminfo database or something like this?

At this point I'd bet it's a slang misconfiguration + a slang bug triggered by this misconfiguration.