Follow-up Comment #27, bug #65474 (group groff):
[comment #25 comment #25:]
> [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.
> 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,
I urge you to take the exhibit to some *roff users of long experience and
measure _their_ expectations.
> and an in-document condition being able to derail the parsing of
flow-control constructs is less than optimal.
I don't think anything's getting derailed here. *roff simply isn't paying off
the expectations of C programmers.
> > 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.
There is no such thing as an empty branch. A branch that looks empty has a
newline on it, which if taken puts a word break (if filling) or line break (if
not filling) on the output.
The very idea that *roff admits an "empty branch" must be banished from the
mind if one wants to model *roff behavior.
$ cat EXPERIMENTS/empty-branch.roff
foo\c
.if \nA \{\}
bar
$ nroff EXPERIMENTS/empty-branch.roff | cat -s
foobar
$ nroff -rA1 EXPERIMENTS/empty-branch.roff | cat -s
foo bar
The braces are as empty as you please _but there is still a newline after
them_. And nota bene, that exhibit works the same in GNU _troff_ 1.22.4,
1.23.0, Git HEAD, and my working copy.
> > 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.
It will alert the user to (likely) unexpected flow of control in some cases;
in others it will spuriously warn, as here.
I think we should not tolerate the issue of spurious warnings.
[comment #26 comment #26:]
> [comment #24 comment #24:]
> > I think my recast[1] of the relevant material in our Texinfo
> > manual is a reliable guide to interpretation.
>
> It's a reliable guide to other-troff interpretation. But in groff, change
that example's ".nr force-word-break" from 1 to 0 and you crash up against bug
#45502.
Hence my pending change, documented there, that will bring consistent behavior
and universal harmony. ;-)
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?65474>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
