On 2/23/24, Larry Kollar <larry.kol...@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.robin...@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.
