Hi onf,

At 2026-09-03T22:27:09+0200, onf wrote:
> On Wed Apr 15, 2026 at 9:29 PM CEST, G. Branden Robinson wrote:
> > Hadn't forgotten about this, but I did put it on the shelf for the
> > sake of getting a release out.
> >
> > I've done that.
> >
> > [...]
> > > I have reported this issue mostly to make groff developers aware
> > > of the deviation from behavior of other troffs and to invite
> > > alternative explanations besides "groff is wrong", which Bjarni
> > > did provide. It is no longer the goal of any of my postings to
> > > convince you to modify groff in any way as I no longer use groff
> > > in production of anything.  So as far as I am concerned, it's
> > > completely up to you whether you remove this deviation or not and
> > > I certainly do not have the time to go digging for historical
> > > troff documents.
> >
> > Okay, well, I happen to have already collected a big mound of dirt.
> > ;-)
> >
> > > My opinion is that it should be removed for the sake of
> > > correctness,
> >
> > I have trouble recognizing your understanding of the feature as the
> > correct one _per the official AT&T troff documentation_.  I readily
> > concede that `sv` interaction with traps is consistently one in AT&T
> > troffs and inconsistent with GNU troff.  However, all the AT&T
> > troffs are genealogically related and this seems to be an obscure
> > feature.
> 
> As I am sure you know, the AT&T troff documentation tends to be terse
> and cannot be treated as some kind of specification.

I entirely agree!  In which case, groff cannot "deviate" (see your words
above) from a specification that does not exist.  Further, as you note,
the various descendants of AT&T troff differ among themselves in certain
behavioral details.

How, then, can one characterize the Platonic ideal from which groff
"deviates"?  What is your method?  If you have one, how do you establish
that it is not subjective and ad hoc?

> > > but I also understand that doing so could break existing documents
> > > which rely on the current behavior, so I don't claim that removing
> > > it is the only reasonable course of action. Of course, if it ends
> > > up not getting removed, it would make sense to document this
> > > difference in groff_diff(7).

This can still be done, of course.

> > Here's what CSTR #54 says.
> >
> > .sv N  -  N=1 V   v
> >     Save a contiguous vertical block of size _N_.  If the distance
> >     to the next trap is greater than _N_, _N_ vertical space is
> >     output.  No-space mode has no effect.  If this distance is less
> >     than _N_, no vertical space is immediately output, but _N_ is
> >     remembered for later output (see `os`).  Subsequent `sv`
> >     requests will overwrite any still remembered `N`.
> >
> > (The annotations mean: (a) an initial value is not applicable; (b)
> > an _N_ of "1" is assumed if the argument is omitted; (c) "v" means
> > the default scaling unit is vees; and (d) "V" means that the unit
> > applicable to the default argument is vees--see `ls`.)
> >
> > I think it's right and proper for `os` to spring page location traps
> > as a side-effect of dumping space on the output.
> >
> > I don't see _any_ reason, apart from slavish bug-compatibility, for
> > `sv` to spring page location traps.
> 
> I have already given you the rationale.

Please restate it.  This thread has a latency of 6 months between
epistles.

> Besides that, there is also historic practice.

Almost always useful; not necessarily dispositive.  I'll offer an
example below.

> I disagree with your assumption that this behavior is shared by all
> the other implementations only due to them being historically related
> or "bug-for-bug" compatible.

Okay.  What evidence supports your inference?

> As a matter of fact, I've recently tested the last page behavior of
> groff, Heirloom troff, and Plan 9 troff, to better understand current
> practice in order to fix neatroff's completely deviant last page
> behavior.

Amazing!  For once, "completely deviant" is an epithet being hurled at
someone other than me.

A Platonic ideal *roff--or a rigorous specification--that exists only in
your head is not useful to others.  For your proclamations of certainty
to persuade others capable of critical thought, you must establish a
factual basis from which they can independently apply familiar rules of
inference.

> You may be surprised to learn that there are differences between Plan
> 9 and Heirloom in this underspecified area.

And you may be surprised to learn that I am not surprised at all!

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

* src/roff/troff/input.cpp (decode_macro_call_arguments): Handle
  right-brace escape sequences in macro arguments consistently with past
  groffs, and Solaris 10, DWB 3.3, and Heirloom Doctools troffs (but not
  _quite_ like Plan 9 troff, whose macro argument handling differs from
  all the others).

As a further detail, official Solaris troff behaves like Plan 9 troff,
whereas the "Solaris10-ditroff" GitHub project behaves like DWB 3.3 and
Heirloom Doctools troff.

My _guess_ is that somewhere between DWB 2.0/System V troff (ca. 1983)
and about 1990, AT&T troff hackers found and fixed a bug.  It filtered
down into some implementations but not others.

> In fact, no two implementations from the above list behave identically
> in all cases.

I entirely agree.  All troff implementations are bound against an
underground rock face with a blazing fire behind them, watching the
shadows they cast on the wall twist and dance chaotically.

> Depending on the edge case, Heirloom sometimes behaves like Plan 9
> troff and other times like groff. So the assumption that Heirloom's
> behavior copies Plan 9 due to being derived from the same sources or
> that it is slavishly "bug-for-bug" compatible is completely unfounded.

It's not completely unfounded; it's a reasonable surmise based on
visible, verifiable genetic descent.  Grab the sources of each and diff
them.  How independent do they look?

> > I propose that, in GNU troff, `sv` continue to behave as CSTR #54
> > says, and not spring traps.  If you want to save some space _and_
> > spring a trap, use both requests.
> >
> > .if !\n(.g .ne 3v \" GNU troff's `sv` doesn't spring traps.
> > .sv 3v
> 
> As I already said, do what you will. This is not a hill I'm willing to
> die on.

But your construction of an idealized, imaginary troff specification,
from which all implementations "deviate", evidently is.

> > Maybe I can get Plan 9 from User Space to join GNU in heresy.[4] ;-)
> >
> > [4] ...but don't count [on] it.  They seem disinclined to accept
> >     patches for behavioral changes without someone undertaking code
> >     hygiene efforts first.
> >
> >     https://github.com/9fans/plan9port/pull/739
> 
> I am surprised they accept behavior changes at all, considering their
> stated goal is merely porting Plan 9 software to Un*x.

Perhaps they are more practically minded than you are.

Here are some further "deviations" they've indulged.

https://github.com/9fans/plan9port/pull/738
https://github.com/9fans/plan9port/pull/736
https://github.com/9fans/plan9port/pull/735
https://github.com/9fans/plan9port/pull/567

Prepare your black-backed Bible for a serious thumping!

A personage we no longer see on the groff list to me seemed to expertly
channel the Colonel "Bat" Guano character from _Dr. Strangelove_.

"I think you're some kind of deviated prevert.  I think General Ripper
found out about your preversion, and that you were organizing some kind
of mutiny of preverts."

To conclude on an earnest note: without a specification, there can be no
"deviation".  What remains is mere difference.  If you want to devise a
troff specification, I recommend you launch a public, collaborative
project to undertake the work, but not set yourself up, à la Jean
Ichbiah, as its editorial primus inter pares.[1]

Regards,
Branden

[1]  I must add that, in my view, Ichbiah is an interesting limit point
     or test case.  I think he did his job shockingly well, almost never
     putting a foot wrong...until _after_ Ada 83 was finalized.

     We remember Cincinnatus with admiration even after two thousand
     years because he not only made himself the archetype of the
     "benevolent dictator" in a straightforward, non-ironic manner, but
     had the vanishingly rare humility to retire back to his farm when
     his project was completed.  Today's black turtlenecks would call
     him a moron for ever letting go of power, once grasped.

Attachment: signature.asc
Description: PGP signature

Reply via email to