From: Ingo Schwarze <schwarze@usta.de>
To: discuss@mdocml.bsd.lv
Subject: Re: Render \*(Pi as pi, not n
Date: Thu, 2 Jun 2011 18:09:06 +0200 [thread overview]
Message-ID: <20110602160906.GA18436@iris.usta.de> (raw)
In-Reply-To: <4DE78C66.8060604@bsd.lv>
Hi Kristaps,
> I don't think this is serious.
Maybe you are right.
However:
> It's trivial to add bits that pass libroff the notion of
> whether it's nroff (-Tascii) or troff (-Teverythinglese).
That's a slippery slope.
As i said in my BSDCan talk
http://www.openbsd.org/papers/bsdcan11-mandoc-openbsd.html
on page 13:
* roff expands high-level macros into low-level requests,
then renders the resulting stream of low-level requests
* mandoc preprocesses low-level requests,
then compiles the remaining high level macros into a syntax tree,
then renders that syntax tree
In roff, the intermediate representation (request stream)
depends on the output mode.
But in mandoc, so far, the intermediate representation (syntax tree)
does *not* depend on the output mode, only on the input file.
Consequently, in roff, a normalizing parser is impossible.
You cannot implement a -Tmdoc output mode in roff.
In mandoc, so far, a normalizing parser is possible.
The command
mandoc -mdoc -Tmdoc foo.1 > foo-norm.1
could be implemented to parse and normalize the mdoc code in foo.1,
guaranteeing that processing foo.1 and foo-norm.1 will produce
the same syntax tree and hence the same output for all output
modes, for all possible input files.
If we go down the route you propose, that is no longer possible.
mandoc atan2.3 # will produce [-pi, +pi]
mandoc -Tmdoc atan2.3 | mandoc # will produce [-n, +n]
Moving expansion of the predefined strings into roff.c already
gave up the chance to preserve them during normalization.
The file atan2-norm.3 will already turn
.Bq "\-\*(Pi, +\*(Pi"
into
.Bq "\-pi, +pi"
even without this patch. With this patch, it will produce
.Bq "\-n, +n"
> In fact, we should be doing this anyway, which
> will allow us to respond to `.if n' in the Right Way.
For now, i think this is an improvement.
In the long run, i feel more stuff must be moved into the syntax
tree, for example escape sequences, which are just elements,
in a sense very similar to in-line macros. Maybe even string
expansions and definitions. However, this requires unifying
the mdoc(7) and man(7) syntax trees, such that both can use
a number of common elements. Which is a huge project and not
yet well thought out.
Yours,
Ingo
--
To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv
prev parent reply other threads:[~2011-06-02 16:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-02 9:28 Ulrich Spörlein
2011-06-02 9:54 ` Kristaps Dzonsons
2011-06-02 11:15 ` Ulrich Spörlein
2011-06-02 11:57 ` Ingo Schwarze
2011-06-02 13:13 ` Kristaps Dzonsons
2011-06-02 13:22 ` Kristaps Dzonsons
2011-06-02 16:09 ` 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110602160906.GA18436@iris.usta.de \
--to=schwarze@usta.de \
--cc=discuss@mdocml.bsd.lv \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).