Follow-up Comment #25, bug #65474 (group groff):
[comment #22 comment #22:]
> 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.
👍
> 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.
I guess it's legal in the sense that it has a well-defined behavior. But it
certainly doesn't do what any reasonable reader would expect, and an
in-document condition being able to derail the parsing of flow-control
constructs is less than optimal.
> 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.
OK. That should fix the comment #11 discrepancy. I don't see it affecting
the comment #0 one, as that contains no empty branches.
> The problem is that this warning is only _sometimes_ valid.
But that's the problem inherent in the logic used in bug #59434 being only
sometimes valid. The warning alerts the user (certainly alerted me) that the
code isn't processed as expected.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?65474>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
