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

[Thomas Dickey]

On Fri, Oct 13, 2023 at 06:47:45PM -0500, G. Branden Robinson wrote:
> Hi Thomas,
> 
> At 2023-10-08T18:48:07-0400, Thomas Dickey wrote:
> > 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
> 
> I had been building with all defaults, but have since discovered
> --with-hashed-db, --with-manpage-format=normal, --with-shared,
> --with-cxx-shared, and --with-ada-sharedlib.
> 
> There are a _lot_ of configuration options.

true - they rarely become obsolete

https://invisible-island.net/ncurses/INSTALL.html

(fwiw, it has more than xterm or lynx)
 
> > > What should change?  The color/pair count limits or the terminfo
> > 
> > nothing, actually
> 
> Well, maybe... ;-)  See below.
> 
> > 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).
> 
> Okay.  I had read that but didn't put it all together correctly.
> 
> I _assumed_ that ncurses updated its configuration defaults with each
> release to expose the improvements in the ABI.

I'll take a look, and update.
 
> You note above, that is not the case.  To _me_, it seems a reasonable
> thing to do.  Distributors should be familiar enough with the package to
> fix ncurses to an older ABI if they require that for backward
> compatibility.  (Or perhaps do multiple builds for the same purpose.)

They should - but that's a different story.
 
> If I may confess further ignorance, I'm not sure what ABI 7 entails or
> even if it's frozen yet.  I played with the '--with-shlib-version'

It's not (I have a to-do list which actually is short, but have found
distractions).

> option; it takes "rel" or "abi" as values, and either way I get a shared
> object version number ("soversion") that starts with "6".  Using
> '--with-abi-version=7' seems like wandering considerably off the beaten
> path.
> 
> Would it make sense to turn this ratchet (perhaps among others) for
> ncurses 6.5?  People have had a good long time to absorb and prepare for
> the 6.1 changes (almost 6 years), and if they haven't done so, it might
> be because you didn't give them a nudge with updated defaults.

sure - I don't always notice because I (like all of the packagers...)
use a preset script for routine builds.

In my test-packages, I use more features than the packagers, of course.
Compare

https://salsa.debian.org/debian/ncurses/-/blob/master/debian/rules

https://github.com/ThomasDickey/ncurses-snapshots/blob/master/package/debian/rules
 
> I admit, I'm not the one who has to weather the bug reports when people
> who know little about ncurses build and install it and have to field
> complaints from the dynamic loader (or elsewhere) when they run their
> favorite MUA or whatever.  At the same time, if you wait for those
> people, you'll wait forever.
> 
> Regards,
> Branden



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

signature.asc
Description: PGP signature