Re: [man-db, groff] I'd like to help kill off some man(1) hacks

[G. Branden Robinson]

At 2020-08-22T12:49:48+0100, Colin Watson wrote:
> I'd definitely be in favour of simplifying this if possible.

Cool!

> What about mdoc, though?

Urp.  I completely forgot about it.  (Ingo will be so disappointed in
me.)

groff's mdoc implementation is fairly notorious on the groff list for
not working in the build tree; to test it, you have to install it,
because it is a multi-file macro package with an installation hierarchy
that is not mirrored in the source tree.  I think I will need to address
that before making any non-cosmetic changes to it.  A sketch for such a
migration has been roughed out before on the list; it shouldn't be too
bad.

> man doesn't know which macro set the manual page uses when it invokes
> groff.  (It could try to discover it, but that's a whole new set of
> complexity.)  Admittedly, --no-justification is a no-op for mdoc
> anyway, but --no-hyphenation isn't.

Right.  Well, I have some good news; groff_mdoc at least already claims
to support registers cR, D, S, LL, and LT, where they have all the same
meanings they do in groff_man.

So it shouldn't be too disruptive to extend the recognized register (and
string) names compatibly with groff_man(7).  We can always say that the
strings AD and HF are recognized but ignored, as with the registers C,
CS, CT, FT, IN, P, SN, and X.  None of those are already in use.

But yes, real HY support in groff_mdoc would appear to be necessary to
proceed.

> But ... although it does suck, it's not unheard of for man to use
> \n[.x], \n[.y], and \n[.Y] to work out the groff version at run-time
> (see the horror that is locale_macros).  Perhaps we could do that here
> so that the injected requests are a no-op with a sufficiently new
> version of groff, and then drop those at some point in the future when
> old versions of groff are no longer interesting to support?

Sounds good to me.  If you think of something I can do on the groff side
that would make this easier, let me know.

If we can get the PS-and-PDF-font-embedding situation worked out, maybe
that would merit a version bump to 1.23, but even that would make a
version number check only marginally less tedious.  :)

Regards,
Branden

signature.asc
Description: PGP signature