groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Release Candidate 1.23.0.rc1


From: Dave Kemper
Subject: Re: Release Candidate 1.23.0.rc1
Date: Wed, 7 Apr 2021 23:12:59 -0500

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.

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.

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

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]