Hi Branden, 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. > > 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). > > 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. Besides that, there is also historic 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. 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. You may be surprised to learn that there are differences between Plan 9 and Heirloom in this underspecified area. In fact, no two implementations from the above list behave identically in all cases. 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. > 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. > Maybe I can get Plan 9 from User Space to join GNU in heresy.[4] ;-) > > [4] ...but don't count 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. Cheers, onf PS: Cc me in any replies, I am not subscribed.
