Re: groff/-mandoc replacement (OT)

[Kristaps Džonsons <kristaps%kth.se@localhost>]

> I also think it's ludicrous to consider trying to replace groff with
> something half-backed that only barely attempts to handle just one macro
> package's worth of documentation.

Was this really necessary?  Half-baked?  Barely attempts and just one?
The mdocml back-end handles all macros in mdoc(7) -- less Xo/Xc for `It'
 extension.  It does so with a validating compiler and an ontology for
describing macro syntax.  Nothing more or less.

Yes, it's ludicrous to replace troff if a considerable number of
non-mdoc roff documents still exist in base.  Do they?  Should they?
Will they in the future?  mdoc(7) is "used to format the BSD man pages".
 Not the me or ms packages.

I don't claim that mdocml replaces groff or any troff in the
general-purpose roff-y sense.  It's not a roff parser.  What I do claim
is that mdocml allows one to analyse the content of an mdoc(7) document
via a well-defined intermediate form -- not merely the style but the
content, which is all that troff does and will always do.

I further claim that it can deprecate troff for the mdoc package, which,
very arguably, is troff's predominant utility.

But given the pervasive, unchangeable existence of non-mdoc roff
documents, it's indeed ludicrous to think that mdocml would replace
troff in NetBSD.  That certainly doesn't warrant disparaging remarks
about mdocml's quality or extent.

My issue with troff is and always has been that it doesn't preserve the
semantic annotations of mdoc.  troff's intermediate-form output is just
style.  If the input is mdoc, we can't see the meaning of data in
looking at troff output.  It's just italics or bold.  This is great if
one's doing general-purpose type-setting, but I'd like to know about the
meaning of data, not its style -- whether an element is a function type
or a variable name.  It's not that this isn't yet possible with troff:
it never will be, as that's not a design goal for troff.  It is,
however, with mdocml.