Follow-up Comment #22, bug #65474 (group groff): [comment #19 comment #19:] > [comment #18 comment #18:] > > I propose to fix this by killing the warning category along with > > the spuriousness. > > With two longtime groff users (Tadziu and Bjarni, with me still on the fence) arguing that the warning isn't spurious, I wonder if this proposal should be put before a wider audience.
Sure, but I'd like to do that once the 3 of us (you, me, and Paul) are on the same page, so that we aren't arguing any facts, just the advisability of future action. > I think clearly documenting the situation described in bug #59434 would greatly simplify explaining to users why this warning occurs and how to code for groff's nonintuitive flow control. Okay. Yours and Bjarni's claims in that ticket are, I fear, incorrect. The input proffered there *is* legal/valid, and moreover is interpreted the same in all tested AT&T and GNU _troff_s. The "scope" of the `if` request in question isn't "two requests". It's one, because there are no brace escape sequences. The `if` governs the one `ie` and then is done. > If there are incompatibilities between how groff handles .if/.ie/.el and how ancestral and peer troffs do, That is why I worked on bug #45502 before this one and *do* propose to change GNU _troff_ there to align with AT&T behavior. For this ticket, I propose no change in how input is interpreted. What differs is the emission of a diagnostic message that has to be opted into. AT&T _troff_ simply did not expose anything like a notion of the "nesting level of if/else control structures" to the user. GNU _troff_ does, via this one channel. > those should also be fixed or documented I have a fix in my working copy, and aim to document this behavior as well, possibly with something similar to the "supertanker" example already extant in our Texinfo manual. > before axing arguably valid warnings. The problem is that this warning is only _sometimes_ valid. We could talk about bringing it back once I have the "style" warning category set up, and possibly repair the situation by warning in *any* situation where the input nests `if` or `ie` requests without using brace escape sequences. Whether that is tractable depends a lot on how complex it gets to read ahead in the input in the `skip_branch()` function (presently called `skip_alternative()`, but I have a rename pending in my working copy). https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/input.cpp?h=1.23.0#n5700 Anyway, do we agree on the facts? _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?65474> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
