[bug #63827] withdraw contrib/pdfmark

[G. Branden Robinson]

Follow-up Comment #7, bug #63827 (project groff):

[comment #5 comment #5:]
> [comment #3 comment #3:]
> > [comment #2 comment #2:]
> > > ...
> > > More importantly, my simple implementation relies on the '!d'
> > > conditional, which I suspect may be groff-specific, (is it?),
> > 
> > Yes.  Subsection "Conditional expressions" of groff_diff(7) covers
> > it, and the other extensions.
> Thanks, but there is no such subsection, in the version of groff_diff(7) on
my Manjaro (Arch Linux) system.

I'm sorry, I didn't mention that I was referring to the Git version, which is
what I use every day.

The subsection has been present since commit 097b3c6c4e
<https://git.savannah.gnu.org/cgit/groff.git/tree/man/groff_diff.7.man?h=097b3c6c4e>
in May 2020.

> The information is there, but not so easily found.  In any event, I had been
perusing 'info groff', which -- again in the installed version -- does not
make it clear that '.if d...' is a groff extension, at the point where the
conditional operators are described.

You're right, groff's Texinfo manual generally doesn't dwell on what is or is
not a GNU extension.  That was the style it had when Trent and Werner stopped
working on it, and I've preserved that aspect except for deeper syntactical
extensions.

> Provided the implementation which does exist will DTRT, w.r.t. the
expectations from using the groff >= 1.23 implementation, sure.  But if you
don't know for sure that any existing implementation mimics groff >= 1.23
behaviour, all bets are off; you surely *do* want to clobber it.

I am not in fact so sure about this.  Your argument could be extended to every
man(7) macro groff supports.  I would regard the inlining of the entire macro
package (excepting maybe `TH` alone) in the prologue of every man page as too
costly.

I want groff's man pages to serve as examples for other man page writers to
follow, and that would be contrary to the goal, bewildering the novice writer
with an avalanche of details.
 
> > groff's man pages all have that logic at the top and bottom that
> > takes the body of the page out of compatibility mode,
> Sure, but what if that compatibility save, disable, then restore hack
doesn't work?

This isn't a hypothetical; when multiple man pages were rendered, prior to
early in the groff 1.23.0 development cycle, it in fact _never did_ work; see
bug #58162.

>  If the page source is passed through a formatter which doesn't support the
'do' and 'cp' requests, or otherwise support groff extended syntax, then all
kinds of output garbage may ensue.

That's going to be true even if we don't bother trying to turn on
compatibility mode at all (or only do it inside our macro definitions),
because non-CSTR #54 syntax is all over the pages anyway, as I noted in
comment #3 and comment #4.

> > and the pages generally use groff extensions like special characters
> > that aren't documented in CSTR #54, often using the \[foo] syntax
> > that also wasn't supported by AT&T troff.
> In which case, attempting to retain even a modicum of support for legacy
formatting engines is likely a forlorn venture, so why bother?

A couple or three years ago, Ingo was putting a lot of pressure on me to not
"break portability".  At the time I didn't have as clear an idea of what
formatters were out there actually being used, and how groff's man pages had
been falling short of his personal standard for portability for decades--in
many cases since James Clark first wrote them.

Solaris 10 troff will be end-of-lifed along with the rest of it in about 1
year <https://mandoc.bsd.lv/NEWS>--assuming they stick to their announced
plan, so call it a 50/50 chance.  Solaris 11 uses groff.  I don't think anyone
actually uses DWB 3.3 troff as a daily driver.  Plan 9 from User Space troff
is still developed, but is fairly recalcitrant to innovations, apart from
adding the `MR` man(7) macro.  This may be due to lack of attention or a low
developer head count.

So in early 2024 it may be time to look again at updating the backward time
horizon for formatters groff expects its man pages to be processed by.

> I'm inclined to disagree, only to the extent that any legacy formatter may
be confused by them, but maybe I'm just being excessively pedantic.

I take the legacy formatter support question seriously insofar as I have any
actual evidence that legacy formatters are being used.  If we don't concern
ourselves with the empirically measurable, then your same argument can be
employed to argue against the use of features introduced by Kernighan in ~1981
to device-independent troff, or really to anything subsequent to the first
nroff in 1972 or so.

As a case in point, and as I have recently documented (i.e., don't bother
looking for it in your Manjaro man pages), the `SB` macro was an extension. 
It was not in Unix Version 7 man(7) in 1979, the first implementation.  It
wasn't in _any_ man(7) until about 1988, when SunOS 4 introduced it.  James
Clark swiftly cloned it in groff.  As far as I know it was never implemented
in any other proprietary troff.  But the maintainers of the Korn Shell, which
ran on just about every Unix, employed it in their ksh(1) man page early on,
never looked back, and if any users complained about its unportability, they
were apparently ignored.

This should have offended Ingo Schwarze and prompted one of his prophecies of
doom; it's just as bad as my/P9US's `MR` because text will be silently omitted
if the macro isn't supported.  (He has a slightly higher tolerance level for
macros that don't take text arguments.)

But what has happened in practice?  Apparently, no one noticed or cared, and a
lot of people assumed it was "standard" when it wasn't.  Plenty of people
moved away from ksh to something else, but I've never heard a complaint that
the unportable man page was the reason.  (There were much better ones, from
licensing to feature creep.  Too much of it got standardized in POSIX as it
was, and the hasty adoption of aliases as a standard feature has caused
problems literally to this very day.  Yes, I mean 24 February 2023.
<https://austingroupbugs.net/view.php?id=1630>)

> > The idea is to get something that works on Heirloom Doctools troff,
> > mandoc, and older versions of groff.  This doesn't work perfectly in
> > general, but for the MR feature specifically, it does.

> Fair enough, provided we're happy to abandon any hope of legacy formatter
support otherwise.

I think whether we do, or have done this, depends on how one defines "legacy
formatter support".

Breaking the renderability of man pages on a system that someone does real
work on is an anti-goal.  Of mine, and I assume of others.

Breaking the renderability of man pages on systems that are only run for
historical research, I may find a regrettable necessity; I won't break them
for _fun_, but if I implement _any_ change to groff (or man(7)) I usually have
a reason that is compelling to me because doing so leads to lengthy
discussions like this one where I defend my decisions.

Breaking the renderability of man pages to systems that are defunct, often
unrecoverably so due to lost hardware or software, or to theoretical or future
Puritan re-implementations of historical systems, I am indifferent to.  I
encourage people to write their own text formatters as a couple of Kernighan's
books suggested.  But a system for deployment to the real world has to deal
with real world specimens of input.  groff's man pages are as valid in that
sense as anyone else's.  More than most, I would venture--if you read down
mandoc(1)'s NEWS file <https://mandoc.bsd.lv/NEWS>, you will find numerous
features, many well down into the weeds of the formatter, that Ingo or
Kristaps before him had to implement to sensibly process man pages not written
by groff's developers.

Put much more simply, I want to avoid _regressing_ portability, which implies
a measurable baseline for comparison--real code being used by real people. 
Objections to new "unportabilities" because they negatively affect unwritten
formatters or nonexistent users should not be credited.  There may be other
reasons to object to a feature, such as poor design or implementation, but
deploying unsupported claims of unportability is fallacious argument.

I trust you will note that when Alexis demonstrated on the groff list that I
had broken portability to real systems
<https://lists.gnu.org/archive/html/groff/2023-02/msg00102.html>, rather than
arguing with him as I am doing with you, I responded within hours, having
reproduced the problem and determined that it was a show-stopper
(release-blocker).  Within 24 hours I had the change reverted and replaced
with one that works.

That's the power of empirical measurement and reproducible results.  


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63827>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/