Tickets #4137 & #4821: true color support with ncurses and 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.

If the terminal does not support 256 colors but does support true color, allow the use of 256-color skins by adding a translation layer that computes direct color values from 256-color palette. So 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]

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.

[ossilator]

i just skimmed it (and don't intend to go further).

[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)

So, we have confirmed the new capability names for separate RGB, intended to be included in terminfo and ncurses by @ThomasDickey in the future:

https://lists.gnu.org/archive/html/bug-ncurses/2025-10/msg00086.html

It follows today's Emacs implementation.

[horkykuba]

Made changes suggested by @ossilator and improved documentation in comments

[zyv]

What do you think @mc-worker & @egmontkob ? I'm not a color-user, but code-wise I don't think I have anything to request, so I'm wondering if we can merge it now.

[egmontkob]

I only skimmed over the first iteration the code, on the high level it looked about as reasonable (incl. workarounds for ncurses's limitations) as it could be, also survived a bit of testing from me.

Also, I know I shouldn't go personal, but based on his debut contributions I have a pretty good trust in horkykuba's work.

Yup let's land it and see how it goes.

[horkykuba]

Thank you guys.

Fyi, I also plan to add support for setb24/setf24, which @ThomasDickey has confirmed as future official capabilities for ncurses/terminfo:

So, we have confirmed the new capability names for separate RGB, intended to be included in terminfo and ncurses by @ThomasDickey in the future:

https://lists.gnu.org/archive/html/bug-ncurses/2025-10/msg00086.html

It follows today's Emacs implementation.

However, I'll do that in a separate PR.

[zyv]

/rebase

[zyv]

@horkykuba, thank you for your contribution!