help / color / mirror / Atom feed
From: Ingo Schwarze <>
To: Baptiste Daroussin <>
Subject: Re: Strange error on a manpage
Date: Sun, 28 Dec 2014 11:35:37 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Baptiste and Franco,

Franco Fichtner wrote on Fri, Dec 26, 2014 at 09:56:08PM +0100:
> On 26 Dec 2014, at 21:36, Baptiste Daroussin <> wrote:

>> The FreeBSD's netmap(4) manpage has 2 failures that seems weird to me
>> mandoc: ./netmap.4:932:2: ERROR: skipping unknown macro: ...
>> mandoc: ./netmap.4:967:2: ERROR: skipping unknown macro: ...
>> What seems weird: it finds ... in .Bd section and consider it as an
>> error, I would expect mandoc not to try to resolv macros inside a .Bd
>> section, am I wrong?

Here is what the mdoc(7) manual says below "Bd":

     Display blocks are used to select a different indentation and
     justification than the one used by the surrounding text.
     They may contain both macro lines and text lines.

It is a somewhat common misconception that .Bd would disable
macro processing, but that's not at all what it does.

The manual continues:

      -literal   Produce one output line from each input line, and do
                 not justify the block at all.  Preserve white space
                 as it appears in the input.  Always use a constant-
                 width font.  Use this for displaying source code.

So even that does *not* disable any macro processing.

> vim syntax highlighting

Syntax highlighting tends to be crap.  I cannot think of any worse
syntax checker than a syntax highlighter.  If you want to do syntax
checking, use a validating compiler (or interpreter, depending on
the language in question).  Take syntax highlighting for what it
is: half-assed, useless guesswork that is usually wrong when it

I would consider vim to be particularly non-authoritative.

> picks these lines up as well.  It must parse them in order to
> find `.Ed',

That is true, but a rather weak reason: For example, the roff(7)
.if request does parse subsequent lines specifically for the ..
end-of-conditional request as well as for sub-conditionals, but all
the same disables most other request processing and all macro
processing.  So it is possible - and in some situations implemented -
to *selectively* disable request and macro processing.

> so I think the error correct.

It is, but the true reason is that the mdoc(7) language intentionally
does not contain any macro to (temporarily) disable macro processing.
Escaping is always needed, in any context.

> The line can be escaped using `\&...' or replaced by an empty
> line.

That's the conventional way to escape leading "." and "'", indeed.

>  Maybe wrapping them into a C comment would also be ok.

That sounds like even better style for the particular case at hand.

 To unsubscribe send an email to

      parent reply	other threads:[~2014-12-28 10:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-26 20:36 Baptiste Daroussin
2014-12-26 20:56 ` Franco Fichtner
2014-12-26 21:02   ` Baptiste Daroussin
2014-12-28 10:35   ` Ingo Schwarze [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).