.nr weirdness

.nr weirdness

[Anthony J. Bentley]

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.

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" (roff(7) only describes .nr as taking
two arguments, and if I take off the last one, it gets initialized
properly).

- 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.

- In mandoc, there's a newline after the ".IP \n+[step]." gets output.
Groff doesn't print one.

That's all for now...

-- 
Anthony J. Bentley
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv

Re: .nr weirdness

[Ingo Schwarze]

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