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

[Dave]

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

[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 are using "predicate" in the sentential sense; I am
> using it in the (formally) logical sense.

Right, sorry for the ambiguity.


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

But, as this thread has covered, that did work in Ye Troffe Of Olde, and as
you note, there might even have been a use for it:

> There are indeed more straightforward ways to skin that
> particular cat.  But the foregoing is not insane as I read
> CSTR #54.

I concede that you're more creative at abusing the parser than I am.  (I also
never noticed the similar "supertanker" example in the manual until you
pointed it out.)

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

> He simply didn't write enough test cases for his formatter, saith I.

What is the sound of no jaws hitting the floor?

> 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.  (The more insidious case of bug #59434 issue will give C coders
far more ulcers.)

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


    _______________________________________________________

Reply to this item at:

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

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