ncruses init_extended_pair, init_extended_color, extended_color_content, extended_pair_content

[GitMensch]

These were added to ncurses in early 2017 and are documented in its manpage.
I assume that not all ports will support those, but many should be able to do so.

Note: the initial addition from PDCursesMod (without any actual functionality) may be used as a starter (the implementation itself will be different), its current handling may be reasonable for some parts, too.

[wmcbrine]

I don't really see these as useful. COLORS and COLOR_PAIRS are already limited to values well within short range, and are likely to remain so even in future revisions. And init_color() values are 0-1000, also well within short range, while I don't even know what init_extended_color() is supposed to do differently, based on its man page. (Sure, it takes ints, but no greater range is specified.)

I would begrudgingly adopt these for compatibility's sake, only, if they come to be widely used. I hope they are not.

[wmcbrine]

I should add -- ncurses seems to automatically set COLOR_PAIRS to be COLORS * COLORS. While there's a certain logic to that (allowing pairs of every foreground / background combo), it's not actually necessary. But AFAICT, it's the rationale for the extended_pair stuff.

[GitMensch]

I would begrudgingly adopt these for compatibility's sake

That was the idea

only, if they come to be widely used. I hope they are not.

Github is definitely not the place where most curses related stuff happens, but event that shows > 3400 results (and brought up one source that seems to be handle the different color variants (none, classic colors, extended colors) quite reasonable.
But yes, the rationale is that COLOR_PAIRS is outside of short range for "nowadays common ncurses".

Of course I'm interested to see what the possible implementation here brings - do you consider it reasonable to at least adding it as int wrappers for the existing functions "sooner" and possibly consider an actual support of increased COLOR_PAIRS later?

[Bill-Gray]

"...I don't even know what init_extended_color() is supposed to do differently..."

Without it, you can't initialize a color palette index past 32767. (Not a problem you expect to have, I realize.) As you say, the RGB values don't go past 1000; they could have been left as short ints. (Though allowing them to be "real" integers lets you avoid all sorts of nuisance casts.)

Most of those >3400 results look to be cases where somebody declared those functions and then didn't actually use them. 256 colors and pairs seem to be enough for (almost) anybody. (Though PDCurses does implement 768 colors on some platforms.)

I don't regret implementing more than 32K colors and pairs; the end result was actually a little simpler and (usually) less memory-intensive than the previous code. But outside the demo programs that show that the extended colors/functions work, they have been used (as far as I know) a total of zero times, including by me.

The ncurses implementation of >32K colors/pairs is, in my opinion, somewhat flawed anyway. Or at least, more limited than it should be. On the flip side, the new_pair functions actually make management of color pairs (slightly) simpler, and I may add them to PDCursesMod.

[wmcbrine]

Yeah, I did alloc_pair() et al this morning, indirectly inspired by this issue. (And then, I saw there's also reset_color_pairs(), whose usefulness is less clear.) It's a nice idea; it would've been nice if it were always there; but as with most innovations in curses, I'd hesitate to actually use it.

[Bill-Gray]

"...I did alloc_pair() et al this morning..." You beat me to it. I think I have it working, but haven't tested it all that thoroughly. I tried using the ncurses demo_new_pair to test it out, without success thus far. PDCursesMod resizes SP->atrtab as color pairs are needed, and marks unused pairs differently, and there are a few other differences, so I can't really just use your code in this case... though we seem to have the same basic idea, unsurprisingly.

I believe reset_color_pairs() is for use in situations such as the picsmap demo : you allocate all the pairs you need for an ASCII art image, and when you want to redraw, you can just deallocate all of them at once and start over. Guess I could imagine it being useful in any situation where, instead of modifying your allocated colors, it'd be simpler just to go back to your initial (absence of) color pairs.

As you say, actual use of "innovations" in curses can be risky. In particular, I've been burned by the fact that OS/X defaults to an extremely elderly implementation of ncurses, such that you can't really count on much of anything since about 2008 (IIRC) to be present. Caveat programmer.