Re: groff/-mandoc replacement

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

>> "mdocml is a suite of tools compiling `mdoc', the roff macro package
>> for BSD manual pages.  [...]"
> 
> Compiling them to what?

An AST -- mdoc(3) produces an intermediate form from its input.
mdocterm(1), which terminal-encodes its output before printing to the
screen, accepts the complete AST, which has a regular form, and produces
its output accordingly.

The big difference between groff's IF and mdocml's is that mdocml
encodes the /type/ of data as described by mdoc, while groff encodes the
/form/.  Thus, e.g., the nascent mdochtml(1) can have produce CSS tags
in its HTML output allowing people to skin variable names or types
arbitrarily.  It's pretty obvious why:  the mdoc macros are generalised
into pure roff before the IF is produced.

>>       - some constructs not [evergoingtobe] implemented (`Xo'/`Xc')
> 
> What is the recommended way to achieve their effect, then?  A few of my
> own manpages use Xo/Xc because I haven't found any other way to get
> things to come out the way I want.  Does this lift the ten-argument
> restriction that's the main reason for needing Xo/Xc, or what?

mdoc(3) has an internal hard-limit of 32 tokens per line, but this can
be easily converted to be infinite with realloc.  Xo/Xc are rendered
meaningless, which is excellent, because it caused some really, really
uglified situations as specifically follows:

.It Xo foo
bar
.Xc
baz

The mdoc(3) scanner-parser is ad hoc and technically able to handle this
situation: its basis is a syntactic ontology of scope, which, in theory,
can be extended to the above, but it's really ugly for just a single
invocation.

Hope this answers your question.

Thanks,
Kristaps