Re: Release Candidate 1.23.0.rc1

[Dave Kemper]

On 4/10/21, G. Branden Robinson <g.branden.robinson@gmail.com> wrote:
> I share Bjarni's inclinations on this point, but there's a nearly
> 50-year tradition of composing roff documents without sweating the small
> stuff.  According to our troff(1) page and as the saying goes, "most of
> it" (warnings) "is small stuff".

Agreed on both points.  It is similar with Perl (though its tradition
is a mere 30 years old): any serious Perl developer will tell you to
always turn on warnings.  But they remain off by default so as not to
clutter the stderr of users throwing together simple, disposable
scripts.

> True, although this is an in-tree-only tool; I don't view such a
> requirement as being a significant barrier in a developer-facing
> program.

True, but it does require:

1. ...the user to be aware that this is even a step that needs to be
done.  For instance, a clueless user named "Dave" recently wrote to
this list complaining about unexpected stderr output, unaware that
test-groff was setting these flags.  On the other hand, if test-groff
worked the same way as regular groff, a hypothetical clueless
test-groff user who WANTS this extra stderr output need only read the
existing groff documentation to learn how to get it.

2. ...users who periodically build and test new groffs to edit this
script every time a groff is built.  While not an insurmountable
burden, it's certainly more of one than that faced by the
alternate-universe user of a test-groff that does not set these
options but who wants these flags set all the time: this user need
only create an alias including them.  This latter action is also a
standard Unix way of quasi-permanently setting certain flags.  The
edit-the-script-every-time system is less standard in addition to
being more work.

So it's not so much that it's a significant barrier as it is that it's
a higher barrier than the alternate, which follows Unix tradition more
closely.

> If -w, -W, or -b affect the way the standard output stream is produced
> in any way[1], that's a fire tornado of a bug irrespective of
> test-groff's existence.

Yes -- and at present that can't even be tested for via test-groff,
since it makes -b always on and there's no command-line override.