On Thu, Aug 28, 2025 at 11:41:07AM -0400, Bill Gray wrote: > > > On 8/28/25 04:30, Thomas Dickey wrote: > > But thinking about the extensions to the API, it isn't as simple. > > > > + it has to support mixing indexed colors and direct colors, so that one > > can have ANSI blue on top of rgb whatever. > > > > + without lots of interface changes, it needs functions to map to/from the > > rgb triple vs a direct-color number, e.g., using a different range of > > values to make checking simple. > > > > So there's no mode-switching contemplated, but a goal of a small set of > > functions to incorporate direct-colors along with attributes to remind > > caller/called which is used. > > Sounds reasonable. > > About ten years back, PDCursesMod had something close to what (I think) > you have in mind. If you set an A_RGB attribute, you could then set > foreground and background with RGB values. > > A few years later, William McBrine (maintainer of PDCurses) persuaded me > that it was a bad idea (I think "misfeature" was the word he used). He > pointed out that (a) it breaks the existing curses color model and (b) you > don't really need it if you have enough color pairs and colors. It was > simpler and better to just make it possible to have lots and lots of color > pairs and colors, within the existing curses color model. (Well, you > could argue it stretches that model a little.)
yes. but:
With PDCurses/PDCursesMod, you're displaying onto a device that doesn't
require workarounds. A pixel is a pixel.
With ncurses, I'm using terminfo to draw using specific escape sequences.
Those only come in certain flavors. Mixing flavors requires some work.
My original idea was simply to demonstrate how one might use direct-colors,
and pointed out that ordinary text required a special case. With that,
there was a lot of work to (a) allow for large integers, and (b) keep it
ABI-compatible.
In an ideal universe, contributors would further extend it. Of course,
this isn't ideal. So we have full-time complainers. Not contributors.
It helps to read the comments which I put in the terminfo.src file,
since the complainers don't actually use why I say.
Here's the comment above xterm+direct2:
# Emacs 26.1 and later support direct color mode in terminals, using a
# combination of user-defined capabilities and ncurses-dependent
function
# calls. We will not include that here.
#
# Here is a first revision, which (disregarding the reuse of colors 1-7
which
# is of interest only to the numerically illiterate), is compatible
with other
# terminal descriptions written for curses. It relies upon the
extended range
# for numeric capabilities provided in ncurses 6.1:
The complainers had something to say about the 1-7, insisting that they
could see the misused colors. Oddly enough, none of them supplied a picture
to demonstrate.
A couple of years later, I added xterm-direct16 and xterm-direct256, noting
# Other variants are possible, e.g., by using more of xterm's indexed
color
# palette, though the intrusion of indexed colors on the direct-color
space
# would be more noticeable.
That is, advising developers to try out both and see the difference.
Of course, the complainers provided words to insert into my mouth.
They got a picture this time, and continued in the same vein.
Time passes, and I happened to consider what might be involved in making
something that could provide xterm+256color and xterm+direct.
Doing that will have no effect on the complainers, but doing it in the
same framework (same ABI, etc.) presents some challenges.
Now... people who use terminfo are either knowledgeable enough to understand
that a terminfo describes a particular configuration of a terminal, and
that more than one terminfo entry can apply to the same terminal. So
they change between them as needed. That's well supported in the API.
Others don't understand this, and think they want a chimera.
(Taming one seems like a lot of work - I can sympathize).
So I get occasional messages (or read discussions) which flog terms
such as "modern", "standard" (Brandon may know of some technical
term for this, but flogging seems appropriate).
When we can focus on the interesting technical issues, that's good :-)
> In PDCursesMod, I got around all this by having COLORS = 256 + 2^24. By
> default, the first 256 are the "standard" sixteen plus 6x6x6 color cube
> plus 24 grayscales; the remaining 2^24 are RGBs. I bumped up COLOR_PAIRS
> to 2^20 = 1048576 color pairs, which should be enough for anybody.
> (Suffices, albeit barely, for a picture-drawing program on a 1920x1080
> display with a 2x4 pixel font, where each cell may have its own color pair.
> I have a picsmap-like demo and a Mandelbrot set program that use the
> scheme.)
I think that's 259200 cells: 1920 * 1080 / 8
> For both color pairs and colors, memory is only allocated as needed. If
> you set, say, color pair 42, the color pair table is reallocated to have
> 64 entries (next higher power of two). So most programs actually use less
> memory than they did before, when those tables were at fixed maximum sizes.
I do that, too
> The only needed extensions were init_extended_pair(),
> extended_color_content(), etc. Which I already had anyway.
I started here, and that determined the change needed for A_xxx's:
int vid_puts(attr_t attrs, short pair, void *opts, int (*putc)(int));
In the mid-layer, I might do some simple scheme for the color numbers
such as putting the indexed and direct colors in one long range, and
solving one problem that way. But allocating pairs for direct-colors
probably should be confined to alloc_pair (perhaps in a separate heap).
That's for later: in the coming weeks I intend working on mingw+win32
(long story there)
--
Thomas E. Dickey <[email protected]>
https://invisible-island.net
signature.asc
Description: PGP signature
