Hi Guillem,

At 2026-07-13T04:20:00+0200, Guillem Jover wrote:
> I also have to say I found it a bit surprising that these breaking
> changes went into groff, when from what I think I've seen in other
> instances, behavior from very ancient and no longer supported historic
> version of roff/troff seem sometimes to be used as rationale for
> current suboptimal behavior (?).

I pursue several goals that don't always militate action in the same
direction:

* I seek consistent language syntax and semantics.
* I seek not to alter the behavior or rendering of documents relying
  upon _documented_ interfaces and/or behavior.
* I seek to solve problems that have historically gone unsolved by *roff
  systems, increasing the appeal and utility of the system to existing
  and (potentially) new users.

Here are examples from the forthcoming groff 1.25 release that
highlight how these objectives can be in tension.

(For what it's worth, I don't expect these to affect any documents in
the global corpus of man pages.)

*  GNU troff, the formatter, now employs the unusual Roman numerals "W"
   and "Z" of AT&T troff only in compatibility mode.

*  The `dt` request, when given invalid arguments, now does nothing
   instead of removing any existing diversion trap.  This change is
   inconsistent with AT&T troff but more consistent with general *roff
   syntax; as a rule, requests given invalid arguments (and that don't
   process a list of similar objects, as `rm` and `rr` do) perform no
   operation.

*  The `dt` and `wh` requests now enforce their requirement of space
   between their arguments.  While consistent with GNU troff input
   syntax, [said enforcement] is not consistent with AT&T troff.  We did
   not add support in groff's AT&T troff compatibility mode because
   we're aware of no legacy documents that require it.  Example:
   `.wh9i+.5+\n(xxuPT` is, while validly planting a trap for the `PT`
   macro in AT&T troff, an input considerably more cryptic than any
   specimens known to us.

I've never seen a man page that assigned a Roman numeral format to a
register, though I'd bet that a few exist.  I'd bet money, though, that
they don't use such registers to represent magnitudes greater than 3,999
decimal.  My supposition is that the Bell Labs CSRC innovated these
additional Roman numerals so that they could represent the full range of
values of the PDP-11's 16-bit machine registers (to which troff's
registers ultimately mapped) without having to perform a range check if
the troff register's format was Roman.

Similarly, I've yet to encounter a man(7) document that messes with
diversion traps (`dt`) or setting up its own page location traps.
man(7) authors don't tend to (directly) employ diversions at all, and
employing page location traps when a full-service macro package like
man(7) already handles them can be a tricky business--one that requires
awareness of that package's internals.

I strive to make groff operate consistently with AT&T troff behavior and
especially to avoid crashing or abandoning rendering when a concrete
ancient document of which we have a specimen does something surprising.
Our development team intentionally evolves novelties like PDF,
hyperlink, and OSC 8 terminal escape sequences to improve the user
experience.  Usually these two goals are not in conflict.  Sometimes,
however, friction arises when their implementations come into contact.

I feel certain you've faced such challenges in maintaining dpkg.

To get back to broader concerns, balancing the competing pressures of
the goals I've selected for my groff work is a matter of judgment.
Being a human of finite intelligence and insight, my judgment is
reliably going to differ from that of others from time to time.

As I said earlier, I've been as transparent with changes to groff as I
know how to be.  I ask users who care about what groff does and who are
sensitive to change to pay attention and engage our development
community where they feel intervention is warranted.

For general edification, I'm attaching a 2-page PDF of the original
man(7) macro package "spec"--the original man(7) page by McIlroy from
Volume 1 of the Seventh Edition Unix Programmer's Manual.

groff_man(7)'s specification of package behavior is far more detailed.

Regards,
Branden

Attachment: seventh-edition-man-7.pdf
Description: Adobe PDF document

Attachment: signature.asc
Description: PGP signature

Reply via email to