Re: [PATCH 4/5] man/captoinfo.1m: Revise.

[G. Branden Robinson]

Hi Thomas,

At 2023-09-24T19:01:09-0400, Thomas Dickey wrote:
> On Sun, Sep 24, 2023 at 02:14:43PM -0500, G. Branden Robinson wrote:
> ...
> > * Increase precision of discussion.  For instance, speak of standard
> >   I/O streams more explicitly, by reference to the concept instead
> >   of C standard library symbol names.  As another example, an
> >   environment variable's name is not the same thing as its contents,
> >   and should not be discussed as if it is.  A third: talking about
> >   "IBM PC high-half graphics" in reference to CCSID (code page) 437.
> >   We can do better than the dissipated and slovenly discourse of
> >   Unix terminal rooms of the past, where code cowboys jockeyed for
> >   status with the hermeticism of their utterances.
> 
> fwiw, that section was by Eric Raymond in 1995-1996

The language of which I was complaining didn't seem like your style (of
which there are ample exhibits on invisible-island.net), so I guessed
(correctly, it seems) that you wouldn't feel my invective aimed at you.

> > * Refer to XENIX in the past tense; it seems to be a dead product.
> 
> agreed - I used in in 1986 or 1987.

I was still in the kiddie pool with 8-bit micros in that time frame, but
I remember craving bigger iron.  :D  XENIX was the first Unix I ever
heard of, but the first one I _used_ was a near-workalike called OS-9.

> > * Capitalize "ACS" (presumably a DEC reference?).
> 
> as I read it, that's "alternate character set", though how XENIX used
> the feature, I don't know (about half the time, I can answer these
> questions with a manual from bitsavers - the other half, no luck).

Yeah, I dithered on that point.  I find use of ACS in the DEC sense
tough to square with the use of an encoding with no shift state and no
modes.  The whole point of the DEC mechanism, I vaguely grasp, was to be
able to switch in partial replacements of the 8-bit code space (GL and
GR--that stuff).  My grasp of the details is feeble.  ACS might be a
separate feature from those...?

> > * Drop explicit indentation from `TP` call in "FILES" section.  The
> >   ncurses man pages seem to follow no consistent format here (cf.
> >   infocmp.1m, ncurses.3x, panel.3x, term.5, and terminfo.tail, each
> >   taking a different approach).  I choose the simplest.
> 
> hmm - TP wants to indent everything by 8 columns, which in nested
> lists eats a lot of space.

Strictly, it's 7n indentation on terminals and 7.2n on typesetters.
But, yes, that does put the first indented character in column 8 (after
whatever the base paragraph indentation is, which you might be happy to
learn is coming _down_ from 7n/7.2 to 5n in groff 1.24[1]).

`RS` and `RE` are relatively lightly used in the ncurses man pages, but
they do enable nesting with control of what I'm at pains to term the
"inset amount", because it is handled distinctly from paragraph
indentation.  groff_man_style(7) in groff 1.23.0 explores and
demonstrates these issues carefully, motivated largely by my own
frustration with learning the interaction of these features in 2017.

At any rate, I would point out that there's no nesting going on in the
"FILES" sections of the ncurses man pages.  I readily concede that the
"standard indentation" of 7n/7.2n[2] isn't fit for every application;
that's why `RS`, `TP`, and `IP` permit its override.

If you could shed some more light on what your concerns are here, I
might make better guesses when preparing patches.

Regards,
Branden

[1] 
https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?id=330f90485dfa57c723bd0e4b918f170b8f922a78#n75
[2] ...or whatever the user--meaning the reader, not the man page
    author--overrides it with via customization of the `IN` register.

signature.asc
Description: PGP signature