From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailout.scc.kit.edu (mailout.scc.kit.edu [129.13.185.202]) by krisdoz.my.domain (8.14.5/8.14.5) with ESMTP id rBFLsWW8025759 for ; Sun, 15 Dec 2013 16:54:32 -0500 (EST) Received: from hekate.usta.de (asta-nat.asta.uni-karlsruhe.de [172.22.63.82]) by scc-mailout-02.scc.kit.edu with esmtp (Exim 4.72 #1) id 1VsJdu-0002B9-Kq; Sun, 15 Dec 2013 22:54:30 +0100 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1VsJdu-0002wR-JB; Sun, 15 Dec 2013 22:54:30 +0100 Received: from iris.usta.de ([172.24.96.5] helo=usta.de) by donnerwolke.usta.de with esmtp (Exim 4.72) (envelope-from ) id 1VsJdu-0005xm-HS; Sun, 15 Dec 2013 22:54:30 +0100 Received: from schwarze by usta.de with local (Exim 4.77) (envelope-from ) id 1VsJdu-0006EN-9F; Sun, 15 Dec 2013 22:54:30 +0100 Date: Sun, 15 Dec 2013 22:54:30 +0100 From: Ingo Schwarze To: "Anthony J. Bentley" Cc: discuss@mdocml.bsd.lv, josh@elsasser.org, james@calminferno.net Subject: Re: .nr weirdness Message-ID: <20131215215430.GA30435@iris.usta.de> References: X-Mailinglist: mdocml-discuss Reply-To: discuss@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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