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/
