Re: Confusion about NCURSES_PAIRS_T

[Chih-Hsuan Yen]

Thomas Dickey <address@hidden> 於 2019年4月15日 週一 下午4:36寫道：
>
> On Mon, Apr 15, 2019 at 02:57:56PM +0800, Chih-Hsuan Yen wrote:
> > Hi NCurses experts,
> >
> > Currently (v6_1_20190413) NCURSES_PAIRS_T is defined as `short`, and
> > in function `pair_content()`, the first argument `pair` accepts
> > 1~COLOR_PAIRS-1, which is 1~65535 in some terminal types (e.g.,
> > xterm-256color, screen-256color). Does that mean NCURSES_PAIRS_T
> > should be a type with a larger range?
>
> no - that would make ncurses incompatible with X/Open Curses,
> rather than being an extended implementation.
>
> I introduced NCURSES_PAIRS_T in 2014:
> https://invisible-island.net/ncurses/NEWS.html#t20140201
>
>         + add/use symbol NCURSES_PAIRS_T like NCURSES_COLOR_T, to illustrate
>           which "short" types are for color pairs and which are color values.
>
> referring to this in curses.h:
>
> /*
>  * The standard type used for color values, and for color-pairs.  The latter
>  * allows the curses library to enumerate the combinations of foreground and
>  * background colors used by an application, and is normally the product of 
> the
>  * total foreground and background colors.
>  *
>  * X/Open uses "short" for both of these types, ultimately because they are
>  * numbers from the SVr4 terminal database, which uses 16-bit signed values.
>  */
> #undef  NCURSES_COLOR_T
> #define NCURSES_COLOR_T short
>
> #undef  NCURSES_PAIRS_T
> #define NCURSES_PAIRS_T short
>
> X/Open Curses uses "short" in function-prototypes (but does not document
> details of data structures).  It's not possible to change the function
> prototypes to use "int" without being incompatible.
>
> I added NCURSES_COLOR_T (and NCURSES_SIZE_T) in 2000 while considering
> this problem:
>
> https://invisible-island.net/ncurses/NEWS.html#t20000429
>
>         + add symbol NCURSES_SIZE_T to use rather than explicit 'short' for
>           internal window and pad sizes.  Note that since this is visible in
>           the WINDOW struct, it would be an ABI change to make this an 'int'
>           (prompted by a question by Bastian Trompetter
>
> That is actually "configurable", but (currently) not worth the
> trouble to extend it:
>
> /*
>  * The internal type used for window dimensions.
>  */
> #undef  NCURSES_SIZE_T
> #define NCURSES_SIZE_T short
>
> Sure: some newer/improved terminal descriptions cannot be represented
> in a standard X/Open Curses implementation.  To do this, I used new
> functions and an unused parameter in several functions to pass the
> extended color values to the library.
>
> I spent most of 2017 working on this, taking into account
> binary compatibility:
>
> https://invisible-island.net/ncurses/announce.html
> https://invisible-island.net/ncurses/ncurses-slang.html
>
> But what you're describing is a constraint within the python curses binding,
> which I can only give advice about.
>
> > Noticing this when debugging https://bugs.python.org/issue36630.
>
> The basic problem there is that no one's gotten around to improving
> the python curses binding to handle the newer terminal descriptions.
>
> --
> Thomas E. Dickey <address@hidden>
> https://invisible-island.net
> ftp://ftp.invisible-island.net

Thank you very much for the rationale and details! I'll check how to
extend CPython to support new terminal desciptions.

Regards,

Chih-Hsuan Yen