Follow-up Comment #4, bug #52526 (project groff):
[comment #3 comment #3:]
> > Is this a manifestation of bug #45502?
>
> I'm going to say no? According to what we see there, AT&T troff has an
extra-special syntax case where if there are no tokens (or spaces only?) after
the conditional expression of an .if or .ie request before a newline, then the
newline is ignored.
>
> This is a hypothesis. I should fire SIMH back up and see. Or read the
V7/Heirloom source.
The above turns to be wrong--in fact, it seems to be backwards. Heirloom
Doctools troff and V7 Unix troff both produce the same output for the
following input.
$ cat if.roff
.if \nb
one
.nr a 1
.if !\na
two
.br
.pl \n(nlu
That output being
one two
This is what I would have expected given the documentation I just freakin'
_wrote_ not too long ago.
Imagine, then, my shock when groff itself didn't behave this way.
$ groff -Tutf8 if.roff | od -c
0000000
And that's groff 1.22.4, not something I horked up on Git HEAD.
I'm thinking the above is indeed a manifestation of bug #45502.
I think Carsten was right, but it was hard for me to see that because he
characterized the syntax used as "wrong". It wasn't wrong, just degenerate.
He also, I feel, inaccurately characterized the specification of the control
structure requests; in "traditional" troff, whitespace is optional between
both the request and the conditional expression, _and_ the conditional
expression and the "body" of the if/ie.
On V7 Unix we see:
$ nroff
.nra 2
.if\na=2foobar
foobar
[65 blank lines]
Anyway, I guess the balance of the discussion should move back to bug #45502.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?52526>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
