(Generated by groff(1))


NAME [1]

.Mx — Reference extension for the mdoc semantic markup language


.Mx −enable [output-formats]

.Mx −disable

macro key

.Mx −ix [category] key
.Mx −sx

.Mx −toc [output-formats] [−tree output-formats]


Creating referenceable anchors[13]
String cleanup and reference prevention[14]
Freely definable anchors and references[15]
Creating table of contents[16]
Strings that affect mdocmx[17]
Internal extended synopsis[18]


mdocmx(7) introduces referenceable index anchors to the mdoc(7) semantic markup language that is used for UNIX manual pages by defining a single new multiplexer command: .Mx. A precondition for enabling this extension in all involved parts of the manual page formatting system, including the PAGER used to view the formatted output, is to set the environment variable MDOCMX_ENABLE[40] to a non-empty value (the value is necessary to make the variable perceivable on the macro level, i.e., to overcome a deficiency of the troff(1) command set).

The mdocmx(7) reference extension augments the standard mdoc(7) document prologue – .Dd, .Dt and .Os – with the new command ‘.Mx −enable’. It can be restricted to specific output formats by adding those troff(1) output devices for which expansion is desired as further arguments to ‘−enable’; for convenience all typewriter-like devices can be addressed via ‘tty’. It is not an error to specify a device for which no special mdocmx(7) support is available, but such requests are simply ignored.

Because macros driven by single-pass troff implementations cannot create forward references mdoc(7) documents which use this extension need to be preprocessed with the mdocmx(1) preprocessor, which is a regular part of mdocmx(7) and implemented in portable sh(1) and awk(1). Specialized manual formatters and macros driven by multi-pass troff interpreters may not require a preprocessor to support this extension. It is also possible to preprocess the manual once and distribute the resulting document – refer to the COMPATIBILITY[8] section for more on that.

Sometimes it may be desirable to actively suppress any processing of the mdocmx(7) reference extension: this can either be accomplished by using .Mx with the ‘−disable’ argument or by defining the string ‘mx-disable[34] ’, as in

$ < xy.z mdocmx.sh | troff -Tutf8 -mdoc -a -dmx-disable=1

Creating referenceable anchors [13]
After the extension was ‘−enable’d in the document prologue the third group of .Mx usage forms can be used to enqueue index anchor requests. These requests form a stack which will be consumed (popped) by the later occurrence of a (corresponding) mdoc(7) macro which supports referenceable index entries. The indices are managed with distinct namespaces for each supported macro, meaning that, e.g., ‘.Mx Ic sendmail’ and ‘.Mx Va sendmail’ will create distinct index anchors.

Using the plain macro .Mx without arguments creates a stack entry for which both, the name of the macro as well as the key will be taken from the document content. ‘.Mx macro’ will create a stack entry that will be consumed by the next occurrence of macro only, then taking the key off the document content, whereas ‘.Mx macro key’ creates a stack entry that also has its key defined, and which will be consumed once an exactly matching macro / key pair is seen in the document only. (The EXAMPLES[7] section gives a use case for this form.)

Using the mdocmx(1) preprocessor will also create referenceable anchors for the mdoc(7) section header commands .Sh and .Ss automatically, so that a mdoc(7) macro package which supports the mdocmx(7) extension will be enabled to actually create references with the .Sx command, and, dependent on the output device, cross-references defined via the command .Xr will also be backed with functionality. The following macros gain support for referenceable anchors via .Mx:


Command argument.


Command modifier.


Defined variable or preprocessor constant.


Error constant.


Environment variable.


Command line option (flag).


Function name.


Function name (in function block syntax). This is mapped to .Fn[25] , .Fo has no index by itself.


Internal or interactive command.


An ‘include’ file for, e.g., the C programming language.


File system path.


Variable name.


Variable type, type reference.

String cleanup and reference prevention [14]
Before strings get used for anchor creation or reference look up any surrounding whitespace will be removed, as well as any preceding ‘\&’, ‘\%’ and postposed ‘\&’, ‘\%’, ‘\/’, and ‘\c’ escape characters. However, reference look up can be actively prevented by prefixing two zero-width glyphs (after possible whitespace), i.e., ‘\&\&’.

Freely definable anchors and references [15]
Via the ‘.Mx −ix category key’ and ‘.Mx −ix key’ usage forms anchors can be defined almost anywhere, e.g., ‘.Mx −ix subsubsection "An interesting topic"’ defines the anchor ‘An interesting topic’ for the ‘‘key’’ ‘subsubsection’. The form without a specified category will use the builtin name ‘ixsx’ instead.

References to anchors that have been created via −ix can be made by activating the .Sx search extension via ‘.Mx −sx category’ (or ‘.Mx −sx’ for the builtin ‘ixsx[59]category) followed by a normal local reference lookup:

.Mx -sx subsubsection
.Sx "An interesting topic"

It should be noted that these usage forms are mostly ment for automated conversion tools rather than for human manual creators: their use is non-trivial (which is owed to the implementation of mdoc(7)) and the resulting visual output should always be verified! As a rule of thumb anchors should always be created inside some ‘‘normal’’ text so that they can be attached to something ‘‘physical’’.

Creating table of contents [16]
The final usage form of the mdocmx(7) reference extension allows the creation of a document table of contents, which is of special interest when converting a mdoc(7) document into formats such as HTML, XHTML or PDF. To restrict the creation of the table of contents to special output formats, add the names of those troff(1) output devices for which expansion is desired as further arguments to ‘−toc’; for convenience all typewriter-like devices can be addressed via ‘tty’.

By default only .Sh section headers are a vivid part of the TOC; in order to include .Ss subsections also add a ‘−tree’ argument. Note that if ‘−tree’ is used in conjunction with output-device restrictions it will only affect those devices that appear later on the line.

In the first of the following examples a table of contents will be generated for PDF and typewriter-like devices. In the second example a tree of contents will instead be generated for the output formats PDF and HTML, whereas typewriter-like devices will see a flat table of contents with only section headers.

.Mx -toc pdf tty
.Mx -toc tty -tree html pdf

Strings that affect mdocmx [17]
that due to deficiencies in some implementations of troff(1) strings given on the command line (via option ‘−d’) have to be given an argument in order to be perceived on the macro level.


If defined mdocmx(7) macros will offer some verbosity. In addition not only references will produce visual output, but also anchors.


Has the same effect as ‘.Mx −disable’.


Forcefully turn off any table of contents creation.


Normally compact display is used for the table of contents, but when this string is set an emerged display is used for the first level that lists the headings.


Defining this string can be used to enforce the creation of a table of contents as specified, even if the documents ‘−toc’ configuration wouldn’t create one for the targeted output device. A flat table of contents will be generated unless the string value is ‘tree’.


If defined its content is used as the headline of the table of contents, which can be used for, e.g., localization purposes. The default is ‘‘TABLE OF CONTENTS’’. (Note that if the table of contents has instead been generated by the mdocmx(1) preprocessor then the resulting document already includes a definition of this string to ensure compatibility with, at least, mandoc(1).)


If defined the first level of the table of contents will be numbered.


The .Mx request cannot share a line with other macros, neither in the document prologue nor in its content. Whereas that is mostly owed to the necessity of ensuring (backward) compatibility with environments that don’t support mdocmx(7), it also simplified implementation of the preprocessor.

Internal extended synopsis [18]
In addition to those usage forms that have been described above the .Mx multiplexer command also understands further flags and arguments which are of possible interest for formatter and macro implementors. These further flags and arguments are only generated by the mdocmx(1) preprocessor and are solely ment to communicate the preprocessed state of the document to the actual consumers.

For one a ‘−preprocessed’ flag is appended to the single ‘−enable’ command in the document prologue. And then an additional ‘−anchor-spass’ form is introduced, which takes two or three arguments – the macro (name of the command) for which this defines an anchor as well as its key, possibly followed by a numeric argument that describes the relationship in between section headings: for .Sh commands it defines a running one-based index count of section headers, for .Ss commands it instead specifies the index of the section header they belong to, therefore creating the possibility to generate TOCs.


Only if the environment variable ‘MDOCMX_ENABLE ’ is set to a non-empty value will the mdocmx(7) macros generate the necessary information that the chosen output device of troff(1) can, sufficient support provided, use to generate table of contents, internal as well as external references. All parts of the processing pipeline should be expected to require this environment variable to be set (to a non-empty value).


A complete, but completely fanciful mdoc(7) document that uses the mdocmx(7) extension would for example be:

.Dd April 22, 2015
.Mx -enable tty
.Nm mdocmx-example
.Nd An example for the mdocmx mdoc reference extension
.Mx -toc
Sors salutis et virtutis michi nunc contraria.
.Bl -tag -width ".It Fn _a_e_i_"
.It Ic .Ar
This will create an anchor for a macro
.Ql \&Ic ,
.Ql .Ar .
.It Ic .Cm
Anchor for
.Ql \&Ic ,
.Ql .Cm .
.It Ic .Dv
And an anchor for
.Ql \&Ic ,
.Ql .Dv .
.Mx Ic
.Mx Ic "final anchor"
.Mx Fn _atexit
.It Fn exit
No anchor here.
.It Fn at_quick_exit , Fn _atexit
Not for the first, but for the second
.Ql \&Fn
there will be an anchor with the key
.Ql _atexit .
.It Ic "no anchor here"
.It Ic "final anchor"
Pops the pushed
.Ql \&Ic
.Ql final anchor
macro / key pair.
.It Ic ciao
Pops the
.Ql \&Ic
and assigns the key
.Ql Ciao .


Using the mdocmx(7) extension in mdoc(7) manual pages should not cause any compatibility problems in sofar as all tested environments silently ignore the unknown commands by default. Because of this, and due to the nature of this extension, an interesting, backward as well as forward compatible approach to use mdocmx(7) may be to preprocess manuals with mdocmx(1) on developer machines and instead distribute the resulting documents.


awk(1), mandoc(1), mdocmx(1), sh(1), troff(1), mdoc(7)


The .Mx environment appeared in 2014.


Idea and implementation by Steffen Nurpmeso <sdaoden@users.sf.net>.
Ingo Schwarze <schwarze@openbsd.org> designed the original command semantics.


Be aware that the content of the ‘−width’ argument to mdoc(7) lists etc. is evaluated as if it were normal document content; e.g., in the following example the ‘Fn _atexit’ will be evaluated and may thus get used by .Mx:

.Bl -tag -width ".It Fn _atexit"

When developing a manual it may be helpful to increase verbosity of the mdocmx(1) preprocessor on its standard error I/O channel by using the ‘−v’ command line flag in order to get a notion on what is going on:

$ mdocmx.sh -vv < mdocmx.7 2> stderr.txt | \
  groff -Tutf8 -mdoc -dmx-toc-force=tree -dmx-debug=1 | \
$ cat stderr.txt

Copyright (c) 1997 - 2016, Steffen (Daode) Nurpmeso <steffen@sdaoden.eu>
@(#)code-mdocmx.html-w42 1.11 2016-01-01T18:59:06+0000