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/
