Hi Branden, (Sorry for the missing In-Reply-To; you forgot to Cc me and the list archive's "reply via email" button doesn't seem to work for me.)
On Sun Dec 7, 2025 at 9:19 AM CET, G. Branden Robinson wrote: > At 2025-11-21T20:28:49+0100, onf wrote: > [...] > > Groff gives the same output when the wh line is > > changed to > > .wh 2v+1u x > > > > (in troff mode; in nroff mode, +1v is needed due to lower resolution) > > Strictly, +0.5v plus 1 motion quantum should do the trick. At least it > does for me (approximating "one motion quantum" as ".03v"). > [...] Fair point, I didn't spend too much time examining the nroff behavior. > At 2025-11-23T22:13:29+0100, onf wrote: > > Actually, CSTR #54 does not specify what should happen when sv's > > argument equals distance to next trap: > [...] > > In other words, the reason that ne does nothing when .t == N is because > > another line can fit in before the trap will be sprung. > > That makes sense. > > > However, in sv's case, what we're interested in is whether the given > > SPACE can fit in before springing the trap, not some text, so in that > > case we need the opposite behavior. > > Hmmm. That seems plausible. > > The questions I have are: > > * If we've broken compatibility with AT&T troff in this regard, what has > that cost us? What exhibits of `sv` and `os` usage in practical > documents can we lay our hands on? It may be that `sv` and `os` were > developed first, and then someone noticed that `sv` was being used a > lot without any `os` subsequently, so `ne` was created. Just a guess. I have even less information on this than you do as I don't come into much contact with historical troff documents. > * What's more conceptually consistent? To have `ne` do the exact same > computation as `sv`, or not? I believe I have made a good case above for them to behave differently, which also seems to be supported by the behavior of Plan 9 and Heirloom troffs. > * Do we want to make groff's compatibility mode work like AT&T troff in > this respect, even if we don't conform in non-compatibility mode? If > so, this would become an example of an "engine level", rather than a > syntactical, behavior change to which I recently referred.[1] Provided that AT&T troff actually does behave like that (I tested only Plan 9 troff; I doubt AT&T will differ, but it should be tested itself), the right thing to do is to provide such a behavior at least in compatibility mode IMO. > The most important question to me is the first. If someone can show me > a practical (preferably historical) document that renders correctly with > AT&T troff but not with groff, I'm inclined to give that a lot of > weight. > > Without such an exhibit, I don't see this issue as demanding resolution > in the short term. (At the moment, I'm kind of preoccupied with cutting > a release candidate of groff 1.24.0.) 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, 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). Cheers, onf
