Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: tmux-direct entry only has 8 colors



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


Home | Main Index | Thread Index | Old Index