Follow-up Comment #14, bug #68420 (group groff): [comment #13 comment #13:] > But I did not say CSTR #54 was a _specification_. I said that > it "did not specify" an aspect of behavior.
That may have been what you _meant_ (and I fully agree with it), but what you
wrote, which I quoted, was, "In _my opinion_, because the behavior is
unspecified, no reliable prediction can be made." Not "unspecified by CSTR
#54," but unspecified full stop, there is no possible way to determine what
the behavior should be, it could be chosen by a random-number generator and
still be within spec.
> This road leads to Hyrum's Law.
Sure, any unthinking adherence to some holy work leads to rigid ideology. But
one could also apply that to "unspecified by CSTR #54 = unspecified, period."
There are other sources of truth that can guide us.
> And your point leaves unaddressed the question of what to do when
> distinct AT&T troff implementations disagree _with each other_,
True, because my point is not to establish a rigid ideology, but to point out
that there can be multiple sources of truth, and if they disagree with each
other, some logic and common sense have to be applied. Further, I had no
evidence that the question Martin posed revealed divergent AT&T troff
behavior, so addressing it seemed moot for the present issue.
> I'm not willing to elevate an implementation to specification status.
Well, if the roff language had a specification at all, our lives would be
easier.
But historically in groff development, AT&T troff behavior has been used to
fill in gaps in CSTR #54, and sometimes even to overrule CSTR #54 altogether
(as explored in bug #68366 and bug #64440 issue #2). So it goes against this
history to claim that "unspecified by CSTR #54 = unspecified, period."
Now, to put all the above in perspective: as a practical matter I think this
is largely academic for this ticket's issue. Comment #8 points out that the
construction under discussion is nonidiomatic--but even if it is used, giving
.cc literally any character besides ' avoids the mess altogether. Trying to
set both flavors of control character to the same character doesn't give the
user any novel functionality.
But if various AT&T troffs behave consistently with this input, and if that
behavior is rational, that's a good reason for groff to follow suit, despite
CSTR #54's silence.
> ProofPoint, Inc. is all (or mostly) FreeBSD people? I didn't know that.
Sorry, I misspoke here: I had only skimmed the parts of this ticket concerning
the source document's provenance.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68420>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
