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

[G. Branden Robinson]

Hi Thomas & Ingo,

At 2023-09-30T16:47:32-0400, Thomas Dickey wrote:
[...]
> > -.\" these would be fallbacks for DS/DE,
> > -.\" but groff changed the meaning of the macros.
> > -.de NS
> > -.ie n  .sp
> > -.el    .sp .5
> > -.ie n  .in +4
> > -.el    .in +2
> > -.nf
> > -.ft \*(CW
> > +.
> > +.nr mE 0 \" in an example (EX/EE)?
> > +.
> > +.\" Start example.
> > +.if !\n(.g \{\
> > +.de EX
> > +.  br
> > +.  if !\\n(mE \{\
> > +.    nr mF \\n(.f
> > +.    nr mP \\n(PD
> > +.    nr PD 1v
> > +.    nf
> > +.    ft \\*(CW
> > +.    nr mE 1
> > +.  \}
[...]

> 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 have good news.  I can't reproduce this problem with mandoc 1.14.6,
and when I format with it, the text within .EX/.EE macros is present and
formatted correctly.  So the Right Thing is happening.

What version of mandoc do you have installed?  mandoc has no `--version`
flag (or short synonym thereof).  On my Debian system, "dpkg -l mandoc"
informs me.

[Ingo wrote:]
> In general, it appears that mandoc supports that, see the example
> at the end of this message - but you are aware that both defining
> macros and using conditionals in manual page source code is strongly
> discouraged, right?  Let alone combining both features...

What I'm trying to achieve is portability _to_ AT&T troff, which Thomas
is trying to support still.  Someone who wants that along with
formatters that are maintained (groff, mandoc, neatroff, Heirloom, Plan
9--though the latter two don't get much attention) has no choice.

> So if people do that, they should be aware that they are ruining the
> robustness and likely the portability of their pages, and that fixing
> any bugs or adding any missing features related to such stunts is
> likely to be high effort and low priority while i often have bugs
> open that are high priority and low effort.  So such bugs, if any,
> are unlikely to be addressed in any reasonable time frame and more
> likely to rot for years before getting addressed.

Well, the good news here is, you already did it.  ;-)

> That said, i tried to have a look what is *actually* going on,
> but so far without success.  I believe the patch we are talking
> about is
> 
>   https://lists.gnu.org/archive/html/bug-ncurses/2023-09/msg00088.html
> 
> I tried to apply that patch to both
> 
>   https://invisible-island.net/datafiles/release/ncurses.tar.gz # 6.3
> 
> and
> 
>   https://invisible-island.net/datafiles/current/ncurses.tar.gz # 6.4-20230923
> 
> but the patch fails to apply to either of the two versions.
> 
> Which version is that patch supposed to apply to?
> Where is the version control system for ncurses (CVS, subversion,
> git, whatever)?

The patches are not only against the current ncurses snapshot, which is
seldom more than a week old, but sequenced strictly behind other patches
I've sent since the snapshot.  So one has to scrupulously apply
everything I've sent to the bug-ncurses list since the last snapshot.

It may not be ideal, but it's a workflow that seems to be operating
effectively for Thomas and me.

> Alternatively, can you show a complete test file exhibiting the problem?

Yes.  For your convenience I'll attach my copy of the clear.1 file
as-is.  It has pre-sed(1) @VARIABLES@ in it but those aren't important--
they're not used to parameterize formatting instructions.

See attachment!

Regards,
Branden

signature.asc
Description: PGP signature