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

[Thomas Dickey]

On Sun, Oct 01, 2023 at 08:40:03PM -0500, G. Branden Robinson wrote:
> Hi Thomas,
> 
> 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: ..
> > 
> > I normally develop with oldstable, and check with Debian testing.
> > Both have mandoc (different versions) producing the same error message.
> > 
> > ii  mandoc         1.14.5-1     amd64        BSD manpage compiler toolset
> > 
> > ii  mandoc         1.14.6-1+b1  amd64        BSD manpage compiler toolset
> > 
> > (resolving this is too late for this weekend, and I'm working to flush out
> > what I have merged/amended this evening).
> 
> No worries, we'll get it sorted one way or the other.
> 
> I noticed a few things about the 20231001 snapshot.
> 
> 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.
 
>     If so, I can prepare a patch to back it out if that seems like the
>     best course.  But I'd still be pretty puzzled why your Debian
>     1.14.6-1+b1 package is complaining about this and my 1.14.6-1 isn't.
> 
>     If not, then I reckon either (a) a glitch happened while applying my
>     patches, and your working copy had got legitimately bad *roff syntax
>     by accident, or (b) the fancy stuff I was doing angered mandoc(1)
>     under these specific circumstances.  If (b) is the case, perhaps I
>     can simply resequence definitions of things to look more like
>     MKada_config.in, and thereby keep mandoc(1) happy.
> 
> 2.  The examples in clear(1) probably won't suffer horribly anyway if
>     filling isn't disabled and the font not switched to monospace.
>     They're already very short (3 are 1 output line, one is 2); all are
>     separated by vertical space below, and 2 of the 4 by vertical space
>     above as well; and their line lengths are short, falling even within
>     the 65n bounds of AT&T troff man(7).  We could hedge our bets by
>     inserting a `.br` request after line 103 (in snapshot 20231001).
>     Such a hedge is less practical for the large Ada example in
>     MKada_config.in.
> 
> 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

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

signature.asc
Description: PGP signature