Re: tmux-direct entry only has 8 colors

[RVP <rvp%SDF.ORG@localhost>]

On Wed, 31 Jan 2024, Thomas Klausner wrote:

> > infocmp kitty+setal
> kitty+setal|set underline colors (nonstandard),
>
> Compare that to terminfo.src:
>
> kitty+setal|set underline colors (nonstandard),
>        setal=\E[58:2::%p1%{65536}%/%d:%p1%{256}%/%{255}%&%d:%p1
>              %{255}%&%dm,
>
> Seems like NetBSD's infocmp (or terminfo) doesn't support setal,
> sounds like a bug.

You have to use `infocmp -x' to see "extra" capabilities like `setal'.

> Again, a couple things seem to get lost (RGB, CO#8, initc@, setb@,
> setf@) but the colors are there.

Ditto.

> I looked at the 'use' and some of them are empty (which makes me think
> NetBSD's infocmp or terminfo are missing more features) and then I
> found:
>
> # Reconstructed from /usr/share/misc/terminfo.cdb
> screen|VT 100/ANSI X3.64 virtual terminal,
>        am, km, mir, msgr, xenl,
>        colors#8, cols#80, it#8, lines#24, pairs#64,
> ...
>
> So it looks to me like the 'colors' from the 'screen' entry via the
> 'tmux' entry overwrite the colors defined by 'xterm+direct'.

This looks like a bug in NetBSD. Minimal reproducer:

```
$ cat tit
tit|TermInfo Test,
# if the second number is >32767, it disappears!
        use=num, use=max,
# putting the bigger one first makes "promotion" happen.
#       use=max, use=num,

max|any number > INT16_MAX,
        colors#32768,

num|any num < INT16_MAX,
        num#111,

$ tic -x tit

$ infocmp -1x -A /tmp/tit.cdb tit
# Reconstructed from /tmp/tit.cdb
tit|TermInfo Test,
        num#111,

$ /opt/ncurses/bin/tic -x -o tit.d tit

$ /opt/ncurses/bin/infocmp -1x -A tit.d tit
#       Reconstructed via infocmp from file: tit.d/t/tit
tit|TermInfo Test,
        colors#0x8000,
        num#111,

$
```

> (xterm-direct analyzed this way also only reports
>
> xterm-direct|xterm with direct-color indexing,
> ...
>    colors#0x7fff, cols#80, it#8, lines#24, pairs#0x7fff,
> ...
> )

Same bug, I think: if any num. capability has a value >0x7fff
(INT16_MAX), then that terminfo entry should get "promoted" to use
32-bit integers. This isn't happening.

> Then it'd be time for a bug report...

Yes :)

-RVP