Add true color support with ncurses and improve S-Lang color detection

[horkykuba]

Proposed changes

Enable true color support in ncurses. TERM must be set to a relevant terminfo entry, i.e. *-direct, *-direct16, or *-direct256.

When set to *-direct256, both 256-color and true color mode can be used at the same time.

Also fix true color detection in S-Lang. S-Lang checks for RGB terminfo capability to enable true color, so we should check for it as well. This means the COLORTERM variable doesn't need to be set when using direct terminfo variants. This also applies to simultaneous 256-color and true color mode.

Update FAQ.

• Resolves: TERM "*-direct" values are not recognized as True Color-capable #4137
• Resolves: Add true color support with ncurses #4821

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]

Just checked what xterm-direct256 does, and accordingly, made a new comment to #4137.

I see the

Shady trick [...] just borrow one degree of red. The user won't notice :)

bit in your change. I guess this is the best we can do, given the underlying library's limitations.

[egmontkob]

I'm not going to do a detailed review. As for the big picture, I think it's as good as it gets (given ncurses's limitations), and it survived nicely some stress-testing for me (like using a 256-color skin with direct16, rejected with an error message as expected).

Thanks a lot!

[horkykuba]

Just checked what xterm-direct256 does, and accordingly, made a new comment to #4137.

I see the

Shady trick [...] just borrow one degree of red. The user won't notice :)

bit in your change. I guess this is the best we can do, given the underlying library's limitations.

Yes, unfortunately. I’m trying to figure out better solution with @ThomasDickey, but the discussion is still not completed - see:

https://lists.gnu.org/archive/html/bug-ncurses/2025-09/msg00032.html

(the rest of this thread is there: https://lists.gnu.org/archive/html/bug-ncurses/2025-08/msg00101.html)

[zyv]

I wonder if the build failure on Solaris is again due to the libmc shared object nonsense (see #4806).

Unfortunately, there is so much activity around the repository now that I totally fell behind on my mail, let alone was able to do something other than skimming through the messages and answering when possible without much thinking...

[horkykuba]

I wonder if the build failure on Solaris is again due to the libmc shared object nonsense (see #4806).

Unfortunately, there is so much activity around the repository now that I totally fell behind on my mail, let alone was able to do something other than skimming through the messages and answering when possible without much thinking...

I completely understand :) That’s because ncurses doesn’t recognize init_extended_pair(), which means it’s using a version of ncurses older than 6.1 (from 2018).

Maybe #ifdef that?

[horkykuba]

Maybe #ifdef that?

Done

[horkykuba]

It appears that Solaris build still fails because although it uses recent ncurses, but it is configured to use ABI 5, which is incompatible with init_extended_pair(). Included into #ifdef.

[horkykuba]

Fixed compatibility code in 8-color mode, improved documentation, included commit with minor improvement of true color skins (differentiate directories and files)

[horkykuba]

Fixed #ifdefs for checking availability of ncurses extended colors

[horkykuba]

Added a commit fixing a bug that caused shadows not to work with ncurses

[zyv]

Added a commit fixing a bug that caused shadows not to work with ncurses

See #4817 for @egmontkob's notes on the conditional. I'm sorry, but I'm confused about you solving this problem by just "dropping" support for non-wide ncurses.

Could you please explain whether it was even "supported" / "working" before for some definition of "working"? If it wasn't working or isn't possible to support it, then dropping it hard might be the reasonable thing to do. But if not, I would actually prefer keeping it working with shadows disabled by changing the conditional appropriately.

The background is that according to my knowledge, most of the distributions do use S-Lang. However, most "exotic" systems like AIX either come with their own curses or ship some very old version of ncurses like Solaris. S-Lang is either not available or undesirable because it needs to be built in the first place and pulls in further dependencies.

This is why I'm happy to have curses/ncurses support working at least to some degree, with however degraded functionality it might be, and I was even questioning if we want to support S-Lang in the long run as the second library. The alternative consideration was to drop both ncurses and S-Lang and roll our own (see #3264), but I personally neither have the competence nor capacity to write and maintain a screen library just for mc.

[horkykuba]

Added a commit fixing a bug that caused shadows not to work with ncurses

See #4817 for @egmontkob's notes on the conditional. I'm sorry, but I'm confused about you solving this problem by just "dropping" support for non-wide ncurses.

Could you please explain whether it was even "supported" / "working" before for some definition of "working"? If it wasn't working or isn't possible to support it, then dropping it hard might be the reasonable thing to do. But if not, I would actually prefer keeping it working with shadows disabled by changing the conditional appropriately.

See my commit message, where I explain it in more detail:

Fix a bug in preprocessor statement that caused shadows to be always
disabled in ncurses, instead of intended behavior of being disabled only
when the non-wide ncurses library was used.

If only the non-wide ncurses library is found, throw an error during
./configure instead of warning, since mc is not compatible with the
non-wide version.

Remove the ENABLE_SHADOWS preprocessor macro as it is redundant.

The problem is that the current mc code depends heavily on the wide ncurses functions, so effectively mc doesn't support the non-wide version of ncurses. This is why I'm dropping the conditional - there is currently no way to compile the code with non-wide ncurses without major code changes.

[egmontkob]

I tried to see if mc works with non-wide ncurses.

tl;dr: Yes it does.

Longer version: It's not a separate package on Ubuntu 25.10, so I manually moved away the /usr/include/ncursesw directory and the /usr/lib/x86_64-linux-gnu/libncurses*w* files, as well as /usr/lib/x86_64-linux-gnu/pkgconfig/ncurses*w.pc.

For some reason yet to be tracked down, ./configure --with-screen=ncurses believes that I do have ncursesw, and places #define HAVE_NCURSESW_NCURSES_H 1 and #define HAVE_NCURSESW_TERM_H 1, causing the build to fail on trying to #include <ncursesw/ncurses.h>. So I manually fixed config.h, commented out those two faulty defines. (Note: setting to 0 doesn't work.) [Update: #4825 this was a ccache bug]

Apart from this little manual intervention, it compiles fine.

This is recent master at e32631a, with the first (faulty) attempt to fix NCURSES_WIDECHAR detection. At my pending 3158 / 4813 line drawing work it fails, probably due to an older (even more faulty) variant of this check, but I'll make sure to fix it.

I am not 100% satisfied with the idea of dropping narrow ncurses support due to the introduction of truecolor support. Mind you, my pending line drawing would also become slightly simpler if we dropped it. However, as long as these ifdefs are reasonably maintainable, I'd prefer if truecolor could be ifdef'ed to depend on widechar, while letting narrowchar still work with reduced (256-color) functionality. I mean, I won't shed a tear if mc drops it in order to become more easily maintainable, but it should be a well-thought-out decision; claiming that it doesn't work anyway (apart from a small autodetection issue) is not true.

(Side note: widechar ncurses has apparently been available since 2000. Yet, it's only built by default on a simple ./configure && make since 6.4-20231021.)

[zyv]

Your last commit reverts #4800. Check it out first. Also see the continued discussion in #4817.

[horkykuba]

I tried to see if mc works with non-wide ncurses.

tl;dr: Yes it does.

My bad. I accidentally checked mc's dependency on wide ncurses with your double-line patch merged, and it showed about 8 wide-dependent functions :) @zyv sorry, you were right.

mc can be indeed compiled with non-wide ncurses. So I reverted the conditional enabling of shadows and fixed it properly instead. To enable this, I added an autoconf check for wide/non-wide ncurses in a separate commit.

[horkykuba]

Your last commit reverts #4800. Check it out first. Also see the continued discussion in #4817.

Not really, it changes the conditional to autoconf generated macro.

[egmontkob]

@horkykuba You rock! (I've verified your widechar detection.)

@zyv You overlooked this, there's another commit underneath similar to the one you suggested, combined with my suggestion to use a more verbose name.

@zyv Could we please land these two commits in master ASAP?

• m4.include: Add autoconf check for wide/non-wide ncurses
• Fix shadows not working with ncurses

My line drawing work also depends on that; that way I could go on in parallel to the beefier truecolor review.

[zyv]

Your last commit reverts #4800. Check it out first. Also see the continued discussion in #4817.

Not really, it changes the conditional to autoconf generated macro.

I'm sorry, I'm getting really confused and overwhelmed by the email flow :-/

@zyv Could we please land these two commits in master ASAP?

• m4.include: Add autoconf check for wide/non-wide ncurses
• Fix shadows not working with ncurses

My line drawing work also depends on that; that way I could go on in parallel to the beefier truecolor review.

If you guys could please extract this change as a separate PR, I will merge it immediately. Then you can rebase your other WIP stuff on top of that...

[horkykuba]

If you guys could please extract this change as a separate PR, I will merge it immediately. Then you can rebase your other WIP stuff on top of that...

Done, #4826.

[horkykuba]

Added commit with compatibility translation from 256 colors to true colors if the terminal supports true colors but doesn't support 256 colors.