Follow-up Comment #11, bug #67992 (group groff): At 2026-01-31T18:04:04-0500, Dave wrote: > Follow-up Comment #7, bug #67992 (group groff): > > [comment #2 comment #2:] >> It's not a regression to issue a diagnostic when encountering an >> ill-formed input document when no diagnostic was issued before. > > Mostly agreed. However, if the new diagnostic points to something > with no apparent relation to the ill-formedness, it's also not a > _pro_gression.
Yes, but that doesn't say much. Every[1] Turing-complete language with
a specification has "implementation-dependent behavior".
>> I need you and Ingo Schwarze to understand that "behavior
>> change" is not synonymous with "regression".
>
> This sounds like a straw-man reduction of both our positions.
I wish it were. I _want_ it to be! Meaning: I want the straw man to be
a distortion I don't have to deal with. The problem I face is that
neither of you articulate a limiting principle to what you characterize
as "regression"--hence my Plan 9 troff SIGFPE example, which I'm willing
to bet is on the other side of this unarticulated boundary--and you guys
wouldn't necessarily champion the same one. If you did articulate such
a limiting principle, then I think I'd have an easier time convincing
the community of groff developers that there's room within *roff's
_loose_ specification to admit variant behaviors.
Deri, for example, is rigid in his expectations of GNU _troff_'s output
format ("grout", as I term it.) Where documentation doesn't support his
rigidity, he points to the implementation as a specification from which
no deviation should be permitted; see bug #63544.
If a system designer does not write down the Law, he finds the users
putting up golden calves right and left...
> The obvious conclusion of a "behavior change = regression" postulate
> is that software should never change, and neither of us has espoused
> that view.
I think Ingo comes close.
See <https://github.com/ischwarze/groff-port>.
"This repository contains work in progress on the textproc/groff
The reason why such a repository is needed is twofold:
Recent GNU roff development suffers from massive amounts of
regressions and gratuitious changes that make providing a stable
groff port very hard.
The gnulib, automake, and autoconf build system used by groff
degrades portability of the software to the point that getting it to
build at all is quite hard and tracking down issues becomes outright
hellish."
..._and yet_...here are some examples of "gratuitous changes" that Ingo
was content to adopt, the existence of which the foregoing screed would
leave one stridently doubting.
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/man_term.c?rev=1.201&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/man_term.c?rev=1.198&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/man_term.c?rev=1.197&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/man_term.c?rev=1.194&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/man_term.c?rev=1.189&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/mdoc_term.c?rev=1.284&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/mdoc_validate.c?rev=1.309&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/tbl_term.c?rev=1.68&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/tbl_term.c?rev=1.66&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/st.c?rev=1.14&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/chars.c?rev=1.51&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/chars.c?rev=1.49&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U&content-type=text/x-cvsweb-markup&sortby=date&ipk=gmIKFMFqKq24GQ9PeZFyvVkeVVh_8yvhk1W4qMaOF_U
It's fine for people to disagree with choices I make, on a discretionary
basis or otherwise. I'm prepared to argue in their defense, and
to alter my position when persuaded.
Slapping the label "regression" on anything is not an argument.
It's question-begging.
[1] Every one for which I've encountered a spec, that is.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67992>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
