Re: reasoning behind default of 5 for CCHARW_MAX

[Thomas Dickey]

On Sat, Nov 23, 2019 at 05:24:14AM -0500, Nick Black wrote:
> Hello, friends in character cell UIs!
> 
> Does anyone know the reasoning behind the default value of 5 for
> CCHARW_MAX? I'm aware that it can be changed (at the cost of
> breaking ABI compatibility) via --with-ccharw-max since NCURSES
> 5.7, but I can't figure out why 5 was originally chosen.

hmm - that dates from mid-1995 (first seen in 1.9.2d, undocumented),
so it was added by either Eric or Zeyd.  They'd have copied from
either a Dell SVr4 or AIX, respectively.

My impression was that one or more of the Unix vendors chose that limit.
(I agree it seems excessive).  When Sven and I implemented wide-characters,
we left it as is.

I have header files for several systems, and can investigate that
to document it (as I did for A_COLOR).

AIX 4 used 5, for instance.  I don't have headers for the Dell SVr4,
but have enough information to make a nice story.

> I've checked X/Open Curses 4.2 (1996) and X/Open Curses 7
> (2009), but both simply say that cchar_t ought be able to hold
> an "implementation-defined" number of wchar_ts, without any
> further guidance that I can find. include/curses.head in a
> ncurses-6.1-20191019 checkout just restates material seen on
> the man page. Is there something I'm missing?

going from SVr4 curses to X/Open, half of the information goes away :-)
 
> I've stared a bit at the "Combining Diacritical Marks" table
> from Unicode 12.1, and...thought I'd mail :). Is anyone aware of
> cases where 5 chars are necessary, useful, and actually work on
> at least one terminal?

well, to answer _that_ question, you'd have to go back in time to
see what the committees took into account when documenting X/Open
Curses.  They didn't leave many clues.

Likely (in 1991-1996), Unicode wasn't a big concern.  Rather,
other encodings with CJK were what I'd suppose they had in mind.
 
> Also, given the semantics of add_wch(3NCURSES), particulary:
> 
> "If wch refers to a non-spacing character, all previous characters
>  at that location are preserved. The non-spacing characters of wch
>  are added to the spacing complex character, and the rendition spec‐
>  ified by wch is ignored."
> 
> The series:
>  - 1 setcchar() + add_wch() for a spacing character
>  - N-1 setcchar() + add_wch()s for N-1 (N<=CCHAR_WMAX)
>     nonspacing characters (with attrs unchanged)
> 
> ought be equivalent to a single setcchar()+add_wch() for the
> same N wchar_ts, correct? Just making sure. If so, it might be
> helpful to remove the "current position...is then advanced" from
> the overall add_wch summary, as it seems to suggest the cursor
> always advances. Alternatively, we could explicitly note that it
> does not advance in the quoted stanza.

yes, a sentence explaining that non-spacing characters don't
advance the cursor wouldn't be overly redundant.

-- 
Thomas E. Dickey <address@hidden>
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: PGP signature