bug-ncurses
[Top][All Lists]
Advanced

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

Re: some entries in terminfo database want too many color pairs


From: Thomas Dickey
Subject: Re: some entries in terminfo database want too many color pairs
Date: Sun, 8 Oct 2023 18:48:07 -0400

On Sun, Oct 08, 2023 at 03:42:01PM -0500, G. Branden Robinson wrote:
> Hi Thomas,
> 
> When building ncurses, I get this:
> 
> "terminfo.tmp", line 1232, col 36, terminal 'fbterm': limiting value of 
> `pairs' from 0x10000 to 0x7fff
> "terminfo.tmp", line 5363, col 36, terminal 'xterm+256color': limiting value 
> of `pairs' from 0x10000 to 0x7fff
> "terminfo.tmp", line 5395, col 36, terminal 'xterm+256setaf': limiting value 
> of `pairs' from 0x10000 to 0x7fff
> "terminfo.tmp", line 5442, col 25, terminal 'xterm+direct2': limiting value 
> of `colors' from 0x1000000 to 0x7fff
> "terminfo.tmp", line 5442, col 40, terminal 'xterm+direct2': limiting value 
> of `pairs' from 0x10000 to 0x7fff
> "terminfo.tmp", line 5457, col 25, terminal 'xterm+direct': limiting value of 
> `colors' from 0x1000000 to 0x7fff
> "terminfo.tmp", line 5457, col 40, terminal 'xterm+direct': limiting value of 
> `pairs' from 0x10000 to 0x7fff
> "terminfo.tmp", line 5479, col 25, terminal 'xterm+indirect': limiting value 
> of `colors' from 0x1000000 to 0x7fff
> "terminfo.tmp", line 5479, col 40, terminal 'xterm+indirect': limiting value 
> of `pairs' from 0x10000 to 0x7fff
> "terminfo.tmp", line 8657, col 36, terminal 'dvtm-256color': limiting value 
> of `pairs' from 0x10000 to 0x7fff

That's expected behavior if tic is built without extended number support.
You'd get that for instance if you didn't configure --enable-widec
 
> ...and indeed it looks like the complaint is not spurious:

:-)
 
> $ grep -B2 'pairs#0x10000' misc/terminfo.src
> # dim, rendering those as green, cyan and gray respectively.
> fbterm|FbTerm for Linux with framebuffer,
>         colors#0x100, pairs#0x10000,
> --
> xterm+256color|original xterm 256-color feature,
>         ccc,
>         colors#0x100, pairs#0x10000,
> --
> xterm+256setaf|xterm 256-color (set-only),
>         ccc@,
>         colors#0x100, pairs#0x10000,
> --
> xterm+direct2|xterm with direct-color indexing (old building-block),
>         RGB,
>         colors#0x1000000, pairs#0x10000, CO#8,
> --
> xterm+direct|xterm with direct-color indexing (building-block),
>         RGB,
>         colors#0x1000000, pairs#0x10000, CO#8,
> --
> xterm+indirect|xterm with direct-color indexing (old legacy building-block),
>         RGB,
>         colors#0x1000000, pairs#0x10000,
> --
> 
> dvtm-256color|dynamic virtual terminal manager with 256 colors,
>         colors#0x100, pairs#0x10000,
> 
> What should change?  The color/pair count limits or the terminfo

nothing, actually

> entries?  I perused curs_color.3x, thinking that perhaps since ncurses's
> terminfo database is likely used by other curses implementations, that
> the warnings might arise from ncurses using narrower data types for
> color and pair counts than others, but that doesn't seem to be the case.
> 
> (Still, it's possible for a terminal to support more numerous colors
> than _any_ library interface bothers to count, but that doesn't seem to
> be the case here; the largest values above are 2^24, which fits in a
> 32-bit int.)

Before ncurses 6.1, the terminal database stored only signed 16-bit numbers.
Starting with ncurses 6.1, it supports a newer format with signed 32-bit 
numbers.

https://invisible-island.net/ncurses/announce-6.1.html

If tic is built without support for generating the newer format,
and it encounters a number greater than 32767, it prints that diagnostic.

If tic is built with support for the newer format, it uses that for
terminal descriptions which have numbers greater than 32767.

Likewise, ncurses 6.1 libraries (wide-character or not) are able to
read the old/new formats.  Again, if not built for wide-characters,
the new format numbers are truncated.

(pre-ncurses 6.1 libraries aren't expected to read the new format).

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]