From: Ingo Schwarze <schwarze@usta.de>
To: "Anthony J. Bentley" <anthony@cathet.us>
Cc: discuss@mdocml.bsd.lv, josh@elsasser.org, james@calminferno.net
Subject: Re: .nr weirdness
Date: Sun, 15 Dec 2013 22:54:30 +0100 [thread overview]
Message-ID: <20131215215430.GA30435@iris.usta.de> (raw)
In-Reply-To: <CAFRrxymUj=-WTw+iGBS3dzFY8XxTU0wkBrSvg9LeU181=1dXMw@mail.gmail.com>
Hi Anthony,
Anthony J. Bentley wrote on Mon, Dec 09, 2013 at 06:36:57PM -0700:
> From sbcl(1):
>
> .nr step 1 1
> .IP \n[step]. 3
> Debugger is disabled, if requested.
> .IP \n+[step].
> Any system initialization file is loaded, unless prohibited.
> .IP \n+[step].
> Any user initialization file is loaded, unless prohibited.
> .IP \n+[step].
> \-\-eval and \-\-load options are processed in the order given.
Even though outside the scope of the man(7) macro set,
that is correct low-level roff(7) code.
So, a port containing that clearly must USE_GROFF for now.
> Here is the diff between mandoc and groff output:
>
> - -1.
> - Debugger is disabled, if requested.
> + 1. Debugger is disabled, if requested.
>
> - 0[step].
> - Any system initialization file is loaded, unless prohibited.
> + 2. Any system initialization file is loaded, unless prohibited.
>
> - 0[step].
> - Any user initialization file is loaded, unless prohibited.
> + 3. Any user initialization file is loaded, unless prohibited.
>
> - 0[step].
> - --eval and --load options are processed in the order given.
> + 4. --eval and --load options are processed in the order given.
>
>
> Here's my superficial analysis of the (distinct?) problems here:
>
> - step is initialized to -1 instead of 1. This seems to be
> due to the extra argument in ".nr step 1 1"
Yes, that was a bug in mandoc(1). It took all the rest of the line
and attempted to convert it to an integer. That failed for "1 1".
I just fixed that in bsd.lv and OpenBSD, stopping the parse at the
first non-digit character.
> (roff(7) only describes .nr as taking two arguments, and if I take off
> the last one, it gets initialized properly).
The third one is an auto-increment step size. As mandoc(1) doesn't
implement auto-increment for number registers yet, parsing and
documenting that third argument would be pointless for now.
I added a note to the TODO file that sbcl(1) would like to use this
missing feature.
> - step should be incremented but it isn't. From quick testing it seems
> that the printed value of "\n+[step]" is always 0 no matter what is in
> step.
Yes, mandoc(1) doesn't implement \n+ and \n-, so it looks for a
register called "+", which doesn't exist, prints "0" and then takes
the string "[step]" for plain text.
I added another note to the TODO file that \n+ is a missing feature.
> - In mandoc, there's a newline after the ".IP \n+[step]." gets output.
> Groff doesn't print one.
Hey, that's *not* yet another bug! ;-)
It's just that the string "0[step]." is too wide to fit into two
characters, so the output handler has to break the line. Groff
would do the same for a tag wider than two characters.
> That's all for now...
Thanks for reporting!
Ingo
--
To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv
prev parent reply other threads:[~2013-12-15 21:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-10 1:36 Anthony J. Bentley
2013-12-15 21:54 ` 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=20131215215430.GA30435@iris.usta.de \
--to=schwarze@usta.de \
--cc=anthony@cathet.us \
--cc=discuss@mdocml.bsd.lv \
--cc=james@calminferno.net \
--cc=josh@elsasser.org \
/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).