Follow-up Comment #5, bug #59434 (group groff):

[comment #4 comment #4:]
> I guess we should get our terminology straight.
> 
> For the infamous [comment #0 original submission] sample code, if COND1 is
false, groff emits the .el warning.  Do you consider this warning spurious?

Yes.

Since at the time the document is composed, we can't know the truth value of
COND1 (otherwise we wouldn't bother to write a conditional predicated on it in
the first place), we must assume that its true branch _can_ be taken. 
Therefore the `ie` is interpreted and a counterpart `el` is expected.
 
> Based on everything written on this so far, I'm inclined to say no: in the
COND1=false case, groff does not see the .ie request, so when it hits the .el,
that .el is, in fact, unmatched; ergo, the warning is of an actual condition
(i.e., not a false positive); ergo, not spurious.
> 
> Have we diverged in our ideas of spuriousness, or are we together so far?

You have put your finger on where we disagree.

As a rule, I think syntax validation operations should be able to rely upon
the syntax of the input remaining valid even within branches that are not
taken.

Under your interpretation, I think, it is permissible to have a syntactically
invalid register definition inside an untaken branch.


.if 0 .ie \nA .nr a\&b 1
.      el     .nr c\&d 2


I think that we must reject this notion, else someone will not only attempt
the foregoing, but change the `\&`s to `\{` and `\}` and insist that we cope.


    _______________________________________________________

Reply to this item at:

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

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


Reply via email to