From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp1.rz.uni-karlsruhe.de (Debian-exim@smtp1.rz.uni-karlsruhe.de [129.13.185.217]) by krisdoz.my.domain (8.14.3/8.14.3) with ESMTP id p0NEereW018223 for ; Sun, 23 Jan 2011 09:40:54 -0500 (EST) Received: from hekate.usta.de (asta-nat.asta.uni-karlsruhe.de [172.22.63.82]) by smtp1.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1Ph17Z-0005iv-0k; Sun, 23 Jan 2011 15:40:49 +0100 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.72) (envelope-from ) id 1Ph17Y-0000BZ-Vz; Sun, 23 Jan 2011 15:40:48 +0100 Received: from iris.usta.de ([172.24.96.5] helo=usta.de) by donnerwolke.usta.de with esmtp (Exim 4.69) (envelope-from ) id 1Ph17Y-0004Xf-VA; Sun, 23 Jan 2011 15:40:48 +0100 Received: from schwarze by usta.de with local (Exim 4.72) (envelope-from ) id 1Ph17Y-0006FN-Ns; Sun, 23 Jan 2011 15:40:48 +0100 Date: Sun, 23 Jan 2011 15:40:48 +0100 From: Ingo Schwarze To: Ulrich Spoerlein Cc: discuss@mdocml.bsd.lv Subject: Re: Bullets everywhere Message-ID: <20110123144048.GB4205@iris.usta.de> References: <20110110221110.GJ23329@acme.spoerlein.net> X-Mailinglist: mdocml-discuss Reply-To: discuss@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110110221110.GJ23329@acme.spoerlein.net> User-Agent: Mutt/1.5.21 (2010-09-15) Hi Ulrich, Ulrich Spoerlein wrote on Mon, Jan 10, 2011 at 11:11:10PM +0100: > prompted by some gratuitous differences in groff vs mandoc output, I > wanted to ask for the rationale here (if any). > > .Bl -bullet > .It > one > .El > > will print the following raw output: > > mandoc: o^Ho one > groff[1] -Tascii: +^H+^Ho^Ho one > groff[1] -Tutf8: ·^H· one > groff[2] -Tascii: ^[[1m+^Ho ^[[22mone > > [1] is groff 1.19.2 (the last GPLv2 release) > [2] is groff 1.20.1 We don't do -Tutf8, so that part is not relevant. Regarding groff-1.20.1 (which i'm using as my reference groff, too), you should always use /usr/local/bin/nroff -c -mandoc -Tascii which will produce "+\b+\bo\bo" just like groff-1.19.2 (though i admit i never tried 1.19, i only use 1.15 and 1.20). Indeed, i have been regarding that difference as annoying for a long time. It is one of the main sources of noise in automatic comparisons, so it is a real hindrance when trying to find bugs, and even worse, when making sure to prevent regressions. For example, fixing it reduces the size of the /usr/src/bin diff from over 1000 to less than 600 lines. Even if terminals capable of showing two glyphs on top of each other are probably rare nowadays, so "+\b+\bo\bo" vs. "o\bo" will rarely make a noticable difference for the user, i strongly feel like committing the following diff, just for binary compatibility. At some point in the past, Kristaps voiced concerns that a similar but less elegant diff i sent out might wreak havoc in the terminal frontends because term.c / term_flushln() would rely on the fact that backspace only occurs in the usual underline and bold sequences, not as a standalone character. Actually, this is not an issue. The only guarantee needed by term_flushln() is that you don't go back more than you advanced, so the diff poses no risk. Besides, the diff also works fine with term.c / encode(). When processing "+\bo", the plus will be encoded, the backspace passed through, and the circle encoded, just as we want it, to produce "+\b+\bo\bo" or "_\b+\b_\bo". So, do you agree with this diff? It survived an OpenBSD build, and the output looks good. > HTML for mandoc 1.10.9: > Postscript! No comment on my part. :) Yours, Ingo Index: chars.in =================================================================== RCS file: /cvs/src/usr.bin/mandoc/chars.in,v retrieving revision 1.13 diff -u -p -r1.13 chars.in --- chars.in 20 Sep 2010 20:43:38 -0000 1.13 +++ chars.in 23 Jan 2011 14:32:06 -0000 @@ -387,7 +387,7 @@ CHAR("rs", "\\", 92) /* Text markers. */ CHAR("ci", "o", 9675) -CHAR("bu", "o", 8226) +CHAR("bu", "+\bo", 8226) CHAR("dd", "=", 8225) CHAR("dg", "-", 8224) CHAR("lz", "<>", 9674) -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv