[bug #65474] [troff] spurious "warning: unbalanced 'el' request" when formatting zic(8) from TZDB project

[G. Branden Robinson]

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/