Re: Release Candidate 1.23.0.rc1

[G. Branden Robinson]

Hi, Dave!

At 2021-04-07T23:12:59-0500, Dave Kemper wrote:
> On 4/7/21, G. Branden Robinson <g.branden.robinson@gmail.com> wrote:
> > You didn't indicate how you're invoking the release candidate groff;
> > if you're using test-groff, you should be aware that this wrapper
> > script turns on all warnings and backtraces.
> 
> So I didn't and so it does.  I missed 2017's commit 655e5020.  Yes,
> this is the culprit for what I'm seeing.

Okay.

> Although Bjarni authored this change, it doesn't seem to really
> address his stated concern, which is that some groff warnings are off
> by default, hiding legitimate problems from users.  That's a
> discussion worth having; the point seems valid, but overturns
> long-established troff practice.

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".

I think it would be prudent to measure the impact of such a change, for
instance by running groff and "groff -ww" over a corpus of real-world
*roff documents and seeing how much worse the latter is.

> But his change merely establishes multiple sets of defaults for
> different ways of running groff, which does not seem to improve the
> situation.  In particular, while test-groff's -ww can be overridden on
> the command line with a later -W, a test-groff user wishing to
> override the -b option has no mechanism for doing so, short of hacking
> the script itself.

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.

> Conversely, if these options are *not* in the script, any test-groff
> user can activate them with a few keystrokes at the command line.

I'm a more active groff developer than most, and I admit that I almost
always run test-groff via a pair of aliases.  So I must concede that
adding a couple more option flags to my aliases would be low-effort.

        $ alias tg tgu
        alias tg='./build/test-groff'
        alias tgu='./build/test-groff -Tutf8'

> Perhaps it comes back to our earlier discussion
> (http://savannah.gnu.org/bugs/?57630) about test-groff's purpose.  But
> it seems more useful as a test script the closer it hews to the way
> groff actually behaves.

This point is only as strong as our tendency to write tests of the
presence of warning diagnostics or backtrace output, all of which always
go to the standard error stream.  At present, we don't do that much.

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.

I could be talked into removing "-b" and "-ww" from test-groff but I
don't think the case for doing so is strong or that it _should_ buy us
anything in terms of fidelity to "actual" groff executable behavior.

Regards,
Branden

[1] the observability of enabled warning types via \n[.warn]
notwithstanding

signature.asc
Description: PGP signature