Re: Macro package loading best practices

[Dave Kemper]

On 2/23/24, Larry Kollar <larry.kollar@icloud.com> wrote:
> But in the case of groff, there’s at least twice as many years of inertia
> (compared to XML) to consider. It really does make sense that an -mm
> based book file should invoke the macro package(s) it needs, but so
> many of us are automatically going to put that -mm on the command
> line (a/k/a “widespread historical expectation”).

Right.  I don't advocate fighting this inertia.  I only advocate
against documenting it as a best practice.

> Now manpages… I seriously doubt we can do much about them.

Nor should we.  They operate under a different set of rules, and are
largely not viewed via users invoking a groff command directly.

On 2/27/24, G. Branden Robinson <g.branden.robinson@gmail.com> wrote:
> And, for completeness, here are the command-line "equivalents":
>
> $ groff -rL=8i -rW=5.5i -rO=0.75i -rV=13.5p -mm foobar.mm
> .H 1 Introduction
> Hello, world!
>
> $ groff -ms foobar.ms
> .nr LL 5.5i
> .nr PO 0.75i
> .nr PS 11p
> .nr VS 13.5p
> .NH 1
> Introduction
> .LP
> Hello, world!

If ms doesn't use the values of LL, PO, etc., until its macro .NH is
called, then why would this not work?

$ groff -rLL=5.5i -rPO=0.75i -rPS=11p -rVS=13.5p -ms foobar.ms
.NH 1
Introduction
.LP
Hello, world!

This would fail if s.tmac blindly initialized these registers without
checking whether they were already set, but a comment in s.tmac
indicates it allows the user to set at least PS and VS on the command
line.

> Viewed this way, mm's approach seems more flexible.

The (minor) tradeoff being that it prevents the document author from
loading the macro set.  But the -ms approach could (and for at least
PS and VS seemingly already does) offer the best of both worlds.