Re: [TUHS] Re: Draft: London and Reiser's UNIX/32V paper, reconstructed

[G. Branden Robinson]

[TUHS dropped from distribution]

At 2024-06-11T15:05:38+0100, Ralph Corderoy wrote:
> G. Branden Robinson wrote:
> > For groff list subscribers, I will add, because people are accustomed
> > to me venturing radical suggestions for reforms of macro packages,
> > I suggest that we can get rid of groff mm's "MOVE" and "PGFORM"
> > extensions.  They're buggy (as the man page has long conceded), and
> > I don't think anyone ever mastered them, not even their author.
> 
> I have quite a lot of old troff -mm source containing lines like
> 
>     .PGFORM 21c-2i 29.7c-1.5i 1i 1
> 
> and they worked fine for me.

Is this trove of documents anywhere available for perusal by the public?

Here's what groff_mm(7) says about `PGFORM`.

     PGFORM [linelength [pagelength [pageoffset [1]]]]
             Set line length, page length, and/or page offset.  This
             macro can be used for letterheads and similar.  It is
             normally the first macro call in a file, though it is not
             necessary.  PGFORM can be used without arguments to reset
             everything after a MOVE call.  A line break is done unless
             the fourth argument is given.  This can be used to avoid
             the page number on the first page while setting new width
             and length.  (It seems as if this macro sometimes doesn’t
             work too well.  Use the command‐line arguments to change
             line length, page length, and page offset instead.)

One might suppose that the parenthetical editorial remark was my own
comment; it was not.

https://git.savannah.gnu.org/cgit/groff.git/tree/mm/groff_mm.man?h=1.14#n1133

(That commit is dated 26 December 1999; at some point after that, the
page lost the "Sorry.".  Dear readers, lay your wagers on who took it
out.  ;-) )

> Part of troff's attraction is it has reached an age where it doesn't
> have breaking changes.

I find this observation ironic given that the foregoing macro isn't
portable to AT&T troff.  One requires groff-like support for long
request names, for a start.

mm(7) isn't man(7); handcuffing oneself by avoiding custom macro
definitions is not recommended for portability.  You can incorporate the
GNU mm `MOVE` and `PGFORM` extensions into your documents' sources,
perhaps under AT&T-compatible two-character names, and thus ease those
documents' portability to many other varieties of *roff.

> Perhaps they should be in a fork of groff.  gbroff?

I had thought perhaps I had heard the last of your invitations to leave
GNU troff development and never return.

Once again, I must decline.

> Though I'd have though an entirely new formatter would give much more
> freedom for experimentation given modern input and output formats and
> greater processing power.
> 
> Meanwhile, Werner's earlier groff is still available and other troffs
> exist.

...and nothing I or anyone else does with GNU troff will change that, so
you can continue to employ those implementations that better suit your
needs.

In fact, I had thought you were using groff 1.17 or earlier, when you
deigned to use groff at all, given how you never forgave its mm package
for moving the page footer in 1.18.[1]  Regardless, I'm glad your memory
of Werner's tenure as maintainer has grown rosier with time, and
apparently come to more closely resemble my own impression: he did a
great deal of excellent work.

But he also added features and changed things all over the place.

Some might consider contributing a bug fix; many bug resolutions--for
instance, my fix to get the argument to mm's `AF` macro to actually
appear in the document when the memorandum-relevant macro calls are
sequenced in a certain (DWB-compatible) order[2]--turn out to be far
below the FSF's "legal significance" threshold of 15 lines of code,[3]
and which prompted your refusal to ever contribute to this project.[4]

I'm attaching an example of the weird inconsistency afflicting
historical troff.  I trust that a discrepancy-sensitive pixel comparator
like yourself ([1] again) will have little trouble spotting the issue.

I am glad to see that you found yourself capable of adaptation;
recalling

>     .PGFORM 21c-2i 29.7c-1.5i 1i 1

above, we can fruitfully compare it to

https://launchpad.net/ubuntu/+source/groff/+bug/42764

and weigh the tenor of your comments accordingly.  Perhaps in your
world, silent accommodation _is_ what forgiveness looks like.

Regards,
Branden

[1] https://lists.gnu.org/archive/html/groff/2009-06/msg00013.html

    In 16 years, no one stepped forward to address that bug report.

    https://savannah.gnu.org/bugs/?24047

[2] https://savannah.gnu.org/bugs/?65865
[3] https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html
[4] https://lists.gnu.org/archive/html/groff/2023-06/msg00017.html

unix-32v-groff-1.22.3-annotated.png
Description: PNG image

signature.asc
Description: PGP signature