On 4/10/21, G. Branden Robinson <g.branden.robin...@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.
