[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: groff/-mandoc replacement
>> "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
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
Hope this answers your question.
Main Index |
Thread Index |