[bug #45502] [troff] .if, .ie, .el parsing incompatible with Unix V7, DWB, and Heirloom Doctools troff

[G. Branden Robinson]

Follow-up Comment #18, bug #45502 (group groff):

[comment #17 comment #17:]
> [comment #16 comment #16:]
> > Sometimes I don't evaluate the truth value of a proposition
> > until I've inspected the machine that interprets it.  😅
> 
> "Trust, but verify," as they say (though the second step seems to render the
first moot).

You won't get far in a quest for cogent reasoning from the ultimate source of
_that_ quite... ;-)


> > Any spaces between the condition and the beginning of anything are skipped
over.


> > 
> > Without too much of a head tilt, I can interpret this as
> > implying that such spaces can be omitted in the first place.
> 
> I have no trouble reading that as saying the spaces are optional.  I have
more trouble reading it as the _branch_ also being optional.

The branch is only optional in the sense that it is interpreted contingently
upon the truth value of the conditional expression before it, or, in the case
of `el`, the inversion of the truth value of the conditional expression in the
counterpart `ie` request.

In this aspect, however, *roff is well within common programming language
practice.

An important insight might be that the human reader of *roff has to remember
to stop and interpret the conditional expression _immediately_ once it is
complete.  Remember that even spaces are not allowed inside a conditional
expression, except, in GNU _troff_ within parentheses.  As soon as that
expression's truth can be decided, you must do so immediately.  Do not pass
go.  Do not collect a space or newline for pleasant, spread-out readability.

(Where *roff is unusual with control flow handling is that
[https://www.gnu.org/software/groff/manual/groff.html.node/if_002delse.html
you can "defer" the "else" branch of an "if-else" structure, and "spring" it
long after many other unconditional operations]).  

> I concede that you're more creative at abusing the parser than I am.

My hand was forced by the demands of composing documentation.


> > I think GNU _troff_'s historical behavior
> > here is an ugly and _unintended_ syntactical extension.
> 
> I'd argue that at this stage, intention is largely irrelevant.  Groff has a
30-year history of working one way, and AT&T troff a 50-year one of working a
different way.  Now it's a question of which set of users' historical use of
this mostly undocumented feature you want to break.

I think few _groff_ documents are likely to trip over this.

1.  If you want


super\c
.if 1
tanker


...then GNU _troff_ has offered `nop` since _groff_ 1.17.

2.  If you want


super\c
.if \n[want-split-compund-nouns]
tanker


...then you probably wrote a comment explaining your cleverness, and it would
then work the same way as AT&T _troff_.

3.  If you want


super\c
.ie \n[want-hyphenated-compund-nouns] -\c
.el
tanker


...then you didn't notice an issue or a discrepancy between AT&T and GNU
_roff_s, because *here*, the newline *isn't* silently discarded.

That is one reason I am so confident that GNU _troff_'s behavior here is
unintended, and a bug.  It should have pushed the newline terminating the
conditional expression back onto the input stream, and it didn't.


> > He simply didn't write enough test cases for his formatter, saith I.
> 
> What is the sound of no jaws hitting the floor?

Lost in the din of applause from brachial single amputees...

> > I think matching AT&T _troff_ behavior here produces a more consistent
grammar.
> 
> I'm not sure you've made this case, but I'll take it on faith, you having
examined the grammar in far more depth than I.
> 
> > Yes, it will be less comfortable for people who read all
> > languages in the expectation that they are C.
> 
> C cares very little where newlines occur, while anyone who's spent more than
five minutes writing roff code knows that it's on the opposite end of that
spectrum.  So visitors from the C-side will pretty quickly toss out their C
ideas of a line of code.  Thus I don't think that's actually a problem for
_this_ issue.

I'm glad to hear it, because that means it should not constitute a site of
resistance to my proposed bug fix.

> (The more insidious case of bug #59434 issue will give C coders far more
ulcers.)

That, I submit, is a matter of the warning diagnostic promising more than it
could deliver.

> > The branch portion of a control flow request in *roff is read
> > _as if it were on an input line by itself_.
> 
> A phrase which is not always true; it's at the heart of the bug #59434
complaint, and in one of the emails linked from there
(http://lists.gnu.org/r/groff/2020-09/msg00001.html), Tadziu proposed an
amendment to make it truer.

I keep striving to get you to decouple your notion of
[https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/input.cpp?h=1.23.0#n5756
how the formatter decides which branch of a conditional it will interpret]
from your notion of
[https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/input.cpp?h=1.23.0#n5700
how the conditionals are nested for the purpose of the "unbalanced 'el'
request" diagnostic].  Why?

**Because the formatter itself handles these separately.**


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?45502>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/