Re: [PATCH 4/9] man/clear.1: Migrate macro usage conventions.

[G. Branden Robinson]

Hi Thomas,

At 2023-10-02T03:50:29-0400, Thomas Dickey wrote:
> On Sun, Oct 01, 2023 at 08:40:03PM -0500, G. Branden Robinson wrote:
> > At 2023-10-01T20:08:05-0400, Thomas Dickey wrote:
> > > > > mandoc doesn't like this 
> > > > > 
> > > > > man/clear.1:52:2: ERROR: skipping end of block that is not open: ..
> > > > > man/clear.1:53:2: ERROR: skipping unknown macro: .\}
> > > > > man/clear.1:65:2: ERROR: skipping end of block that is not open: ..
[...]
> > > (resolving this is too late for this weekend, and I'm working to flush out
> > > what I have merged/amended this evening).

Turns out I can reproduce this after all.  But I have to call mandoc(1)
with its "-Tlint" option; it doesn't occur (for me) in ordinary use.

One resolution to this issue is therefore simply to ignore mandoc's
output here.  The *roff(7) language is (more or less) specified in CSTR
#54 (1976; 1992).  What mandoc accepts is not specified anywhere; it has
a roff(7) page (sometimes installed as mandoc_roff(7)), but that
documents only a subset of what it will accept.

The reason I proposed the complicated stuff that mandoc complains about,
and which Ingo has cautioned me about, is to accommodate the AT&T
troff-descended formatters on the System V-based systems you support
with ncurses.  If I am mistaken about that being a goal of yours, then
I'm happy to simplify my patches and back out some of the complexity
I've already contributed.

> > 1.  My patch to make adacurses6-config use (and conditionally
> >     define) EX/EE _did_ get merged.  Does mandoc(1) complain for you
> >     on that page as well?
> 
> yes, it does (my attention was on clear.1 because that is built in all
> configurations).  I can remove it, depending on how this is resolved.

I'll prepare patches for MKada_config.in and clear.1.

> > 3.  The change to _use_ `EX`/`EE` in clear(1) is merged, just not
> >     the patch to _define_ these macros if the document thinks it's
> >     being prepared for a typesetter using a non-groff-compatible
> >     formatter.  So results will still be correct and attractive on
> >     modern systems, including mandoc(1) 1.14.5 and .6.
> 
> yes - I don't have a useful testcase for old-troff in mind

Can you elaborate on what mean by this?

Taking a guess, I don't know of a reliable and simple means of
determining which formatter is in use.  The `.g` register only gives you
some of the story--that the formatter claims to support groff
extensions.  But that is susceptible to false positives _and_ false
negatives.  Any non-groff formatter could define a register named `.g`,
and mandoc(1) _doesn't_ define it but nevertheless supports many groff
extensions.  Heirloom Doctools troff can simulate AT&T troff _or_ groff,
and has its own extensions besides.

Regards,
Branden

signature.asc
Description: PGP signature