Hi Branden,

On Wed Sep 9, 2026 at 6:54 AM CEST, G. Branden Robinson wrote:
> At 2026-09-03T22:27:09+0200, onf wrote:
> > On Wed Apr 15, 2026 at 9:29 PM CEST, G. Branden Robinson wrote:
> > > [...]
> > > > 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.
> > > [...]
> > > > 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.

Indeed, see my words above and read them more carefully (emphasis
added):
> I have reported this issue mostly to make groff developers aware of
> the deviation FROM BEHAVIOR OF OTHER TROFFS [...]

It absolutely can deviate from the behavior of other troffs; I never
said anything about a spec. What I said is that all other troffs behave
a certain way -- a way which is logical and I explained why -- so
perhaps groff should behave that way too.

> 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?

Please don't mischaracterize my ideas. What groff deviates from is the
easily testable behavior of all the other troffs, not some "platonic
ideal".

[re-arranging]
> 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]

  deviate (verb)
    1. To go off course from; to change course; to change plans.
    2. To fall outside of, or part from, some norm; to stray.
    3. To cause to diverge.

  norm (noun)
    1. That which is normal or typical.
    2. A rule that is imposed by regulations and/or socially enforced
       by members of a community.
    3. A required level of achievement.

(Wiktionary)

Does the behavior of groff's sv fall outside of that which is typical
among troff implementations? It clearly does.

> > 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?

Fine, but in the case of last page handling, it is nonetheless wrong. It
could as well be wrong here too, which is why making such a sweeping
assumption seems like a bad idea to me.

> > > 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",

I would only waste more words reiterating for the third time what I
wrote above. That construction is entirely in your own head.

> evidently is.

No, it is not. I don't have more time for this pointless exchange.
I have responded out of politeness because I don't like leaving
messages unanswered. If you would prefer me not to respond next
time, then I am not going to.

> [...]
> > > 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.

Given how you managed to mock me 3 times in a row for supposedly basing
my suggestions on some nonexistent ideal troff, despite me consistently
pointing, throughout the duration of this thread, to the behavior of
the very much existing Heirloom troff, Plan 9 troff, and neatroff...
I really don't know why I should bother with that. You will ignore what
I'm trying to say anyway.

> > Besides that, there is also historic practice.
>
> Almost always useful; not necessarily dispositive.  I'll offer an
> example below.

Hm, yes. Which is why I offered it alongside a rationale supporting
said practice.

> > 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?

You are the one claiming that they are "bug-for-bug compatible". I
have already given you a counter-example where they definitely aren't,
despite the area in question being considerably underdocumented
(neither the AT&T troff manual nor the groff Texinfo manual explain
it in sufficient detail to judge what is or isn't correct behavior,
so one has to wonder what lead to this divergence between Heirloom and
Plan 9 in the first place). You have yet to produce any supporting
evidence for this claim.

> > 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.
> [...]

That's not true. As far as I remember, I've never said that of groff.
But hey, sorry for notifying you of a "difference" (to use your
vocabulary) from other troffs! I am definitely not going to report
it next time since you know better than all the other troffs anyway.

~ onf

PS. Please Cc me in any replies, I am not subscribed.

Reply via email to