Hi Deri, At 2026-07-30T00:30:49+0100, Deri wrote: > On Tuesday, 28 July 2026 2 0:26:30 British Summer Time G. Branden > Robinson wrote: > > The foregoing is an interesting case. We don't actually need > > preconv, eqn, _or_ pic to generate "automake.pdf". > > > > "automake.mom"'s only non-ASCII character appears in a _roff_ > > comment. > > > > https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/doc/automake.mom?h=1.2 > > 5.0.rc1#n3 > > > > It uses no preprocessor tokens, either (`TS`, `EQ`, `PS`, `[`). > > > > Yet pdfmom(1), in an effort to be helpful I suppose, brings the full > > power of its battle station to bear on poor old Alderaan. > > "This is not the script you are looking for". > > The "redundant" preconv and -p -e -t flags were added to > contrib/mom/mom.am by you in commit a5af2f4d0f0.
I'm not surprised. Possibly I erred in doing so.
Oh no! Whatever shall I do?
$ git grep 'Problem introduced by me' ChangeLog*
ChangeLog: Haible for the concurrent discovery. Problem introduced by me
ChangeLog: John Gardner for the report. Problem introduced by me in commit
ChangeLog: overlooked. Problem introduced by me in commit 111bf3255b, 8
ChangeLog: script so it can fail again. Problem introduced by me in commit
ChangeLog.123: Problem introduced by me in commit 096c2f0567, 16 February.
ChangeLog.123: operator. Problem introduced by me in commits adc1999af and
ChangeLog.123: variable for generated artifacts. Problem introduced by me in
ChangeLog.123: Rename `sP` register to `mP`. Problem introduced by me in
ChangeLog.123: `AC_SUBST()`-itution. Problem introduced by me in commit
ChangeLog.123: generated files. Problem introduced by me in commit 24602f42, 4
ChangeLog.124: Cole for the report. Problem introduced by me in commit
ChangeLog.124: Problem introduced by me in commit e9da162af8, 2026-02-07.
ChangeLog.124: build on Solaris 11/sparc64/GCC 5.5. Problem introduced by me
ChangeLog.124: Kemper for the report. Problem introduced by me in commit
ChangeLog.124: Kemper for the report. Problem introduced by me in commit
ChangeLog.124: Problem introduced by me in commit d22a547b9b, 27 August 2023.
ChangeLog.124: Problem introduced by me in commit 4bdcefea1d, 6 June.
ChangeLog.124: Problem introduced by me in a branch on 7 March 2023, but not
ChangeLog.124: Kemper for the report. Problem introduced by me in commit
ChangeLog.124: Ingi Gislason for the report. Problem introduced by me in
ChangeLog.124: Kemper for the report. Problem introduced by me in commit
ChangeLog.124: Problem introduced by me in commit f3944d6305, 3 March.
ChangeLog.124: James for the report. Problem introduced by me in commit
ChangeLog.124: Problem introduced by me in commit 0b40885e71, 3 November 2023.
ChangeLog.124: van den Hoff for the report. Problem introduced by me in commit
ChangeLog.124: caused by null pointer dereference. Problem introduced by me in
ChangeLog.124: digits at minimum. Problem introduced by me in commit
ChangeLog.124: Problem introduced by me in commit 18697e757c, 22 November 2020.
ChangeLog.124: report. Problem introduced by me in commit 53a9964497, 31 July
ChangeLog.124: Ingi Gislason for the report. Problem introduced by me in
ChangeLog.124: the report. Problem introduced by me in commit df1fc139af, 3
ChangeLog.124: inoperative. Problem introduced by me in commit 4f4b79b8aa, 26
ChangeLog.124: Problem introduced by me in commit eb695ab2b5, 30 October 2021.
ChangeLog.124: {Problem introduced by me in commit 6e45bb0bc6, 4 January, when
ChangeLog.124: continues to pass when corrected. Problem introduced by me with
ChangeLog.124: dependency name. Problem introduced by me in commit 2566b64e0b,
ChangeLog.124: _don't_ match. Problem introduced by me in commit 705be31107,
ChangeLog.124: Thanks to Alex Colomar for the report. Problem introduced by me
If you think I'm embarrassed to admit misjudgment, then you have
mistaken your man.
When making changes, I don't start out with the level of confidence in
my changes that you express of your own. As I've said before, I
outsource my confidence to automated test scripts that anyone can run
and study the outcomes of.
If I make a change that breaks something during a build including a run
of the test suite, yet that breakage is not detected, then our test
harness is inadequate. That's why it's grown from 3-4 tests in 2018 to
almost 370 now.
Occasionally, it's hard to attribute breakage to a defect in the
traditional sense: sometimes two engineers will disagree on whether an
outcome is expected or not because the behavior is un- or
underspecified.
Does pdfmom(1) _have_ a scope? Is it _ever_ inappropriate to use?
Where can the user find the answers to these questions?
> Pdfmom is innocent.
Let's not anthropomorphize scripts. Let's focus on diagnosing and
solving problems.
> diff --git a/contrib/mom/mom.am b/contrib/mom/mom.am
> --- a/contrib/mom/mom.am
> +++ b/contrib/mom/mom.am
> @@ -30,1 +28,1 @@
> - $(PDFMOMBIN) $(FFLAG) $(TFLAG) $(MOM_TFLAG) $(MOM_KFLAG)
> + $(PDFMOMBIN) $(FFLAG) $(MFLAG) -M$(mom_srcdir) -k -p -e -t
>
> Using groff with both mom and ms (with PDFFEAT turned on) will warn
> you if multiple passes (i.e. pdfmom [--roff]) are required.
Yes, and that's a good idea, but I don't know why this diagnostic
procedure is living up in a wrapper script when we could have troff(1)
or groff(1) do so themselves, perhaps by exiting with status 3.
Forward references are not unique to mom(7).
They're not even unique to mom(7) and ms(7) taken together.
They can occur in _any_ *roff document, even one that does not employ a
"full-service" macro package.
We even support them in mdoc(7), a package we support in our mission
statement[1] and yet which fell beneath your notice when you prepared
the "Groff PDF Features".
It's fine, and even laudable, to pilot a generalizable solution in a
narrowly specific way, to nail down concrete matters and avoid
_over_-generalizing or over-specifying a solution in the design phase...
but once you've solved a problem in 2 cases out of N, it's time to start
thinking about how to solve it for all N cases, rather than leaving the
work to someone else to handle cases 3, 4, 5, ...
> Human nature will tend to always use pdfmom once the message has been
> seen.
_Some_ humans' nature will be to do so. Others are jealous of
wall-clock or CPU time, and want to eliminate unnecessary processing.
And we, as groff's developers, should belong to the jealous class,
because we have responsibility for groff's build system, which dogfoods
itself in production of all documentary artifacts except our Texinfo
manual.
This why I was happy to push yesterday the change that got pdfmom out of
the business of producing "automake.pdf".
Why _wouldn't_ we use a thing called "pdfmom" to produce a document
written in mom(7) targeting "pdf"? Don't tell _me_: try to explain it
to a user.
> > 3. pdfmom(1)'s mission needs to be put on a diet.[ibid.] It seems
> > to have mutated into a tool with no charter except to get
> > documents built with brute force, multi-pass processing whether
> > they need that or not, throwing several preprocessors at them
> > whether needed or not, and, recently, sprawling beyond its
> > initial goal of easing production of PDF documents using the
> > mom(7) macro package to generating general "roff" documents, not
> > necessarily using mom(7) (see its `--roff`(!) option) or being
> > produced in PDF format.
>
> Well, this is completely wrong! The ONLY purpose of pdfmom has always
> been to satisfy forward references (the same as pdfroff used to do for
> postscript but avoiding dependency on ghostscript) nothing else - no
> flags added, except -mom if the script is called as pdfmom and -ms if
> it is called as pdfms.
So..."pdf""mom" doesn't _necessarily_ have anything to with PDF
generation nor with the mom(7) macro package.
I appreciate your concession of the point.
> It is you who added the unnecessary flags to the makefile not pdfmom
> herself (I think you owe her an apology).
As you say, "rubbish". Being precious about code is the antithesis of
high-assurance engineering. Treating a pile of bits as if it were a
thing capable of experiencing pain or taking offense is manifestly
careless thought.
"Mr. Treehorn treats objects like women, man!"
> > In other words, having disposed of one Perl script called
> > groffer(1) in groff 1.23.0, we are metamorphosing another Perl
> > script into its replacement.
>
> Rubbish, pdfmom does none of the things you claim.
It's certainly grown to do more over time, with this new `--roff` option
and self-sniffing `argv[0]` behavior reconfiguration, a practice widely
recognized decades ago by POSIX as a bad idea.
https://news.slashdot.org/story/22/09/05/0135254/gnu-grep-38-starts-issuing-warnings-about-using-egrep-and-fgrep
> > Enough!
> >
> > I have some notions of a new approach but they'll need to cook a
> > while longer. I have no concrete timeline for working this out.
>
> I shall look forward to hearing your ideas, but I hope you actually
> look at the code in pdfmom before hallucinating what you think it
> does.
I have indeed had trouble inferring exactly what pdfmom(1)'s purpose is,
since that purpose has, as you concede, expanded.
> I'm afraid the force was not strong in you when you wrote your post.
Good thing I'm not religious, then--as Laplace said of God, "I have no
need of that hypothesis."
Let's do some engineering here.
Regards,
Branden
[1] https://www.gnu.org/software/groff/groff-mission-statement.html
I feel that groff's mission statement _over_-emphasizes the
importance of mdoc(7), but as we're in the midst of one argument
already, I'll defer that one to another occasion.
signature.asc
Description: PGP signature
