Anthony J. Bentley <[email protected]>:
> Funny, that looks almost exactly like what you posted. Since -mdoc
> already exists, is shipped in man(1) with a great many systems
> (certainly all the ones I've ever used), and already has thousands of
> manpages written in it, why extend -man in a backwards incompatible
> manner? Any system which doesn't support -mdoc would certainly not
> support these new -man macros.
I've written an mdoc interpreter. It's in doclifter. And I'm here
to tell you why mdoc is not the solution you're looking for.
It's way, *way* overcomplicated. Part of the reason is design bloat.
Part of the reason is attempts to paper over intrinsic problems with
the line-oriented model of groff markup. Attempts that don't quite
work, inducing cascades of mdoc features that are in reality ugly
workarounds (I'm thinking especially of the .O/.X macro families here).
The result is pure hell for anyone trying to interpret the mess with
anything but groff itself. I believe I am the only person who has
even tried this seriously.
I managed to handle almost all of it, because I am exceptionally good
at the kind of hacking required for the job. But not in fact all of it;
it's one of the major sources of the tiny percentage of pages that
doclifter chokes on and that cannot be fix-patched.
The effort required to get this far with mdoc was extreme even for
me. Thus I consider that effort very unlikely to be successfully
replicated - I doubt anyone else will have the stamina required.
mdoc has overelaborated itself into a hole. It is an evolutionary dead
end, not a solution.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
