From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by krisdoz.my.domain (8.14.3/8.14.3) with ESMTP id p0OF7Sd9028166 for ; Mon, 24 Jan 2011 10:07:29 -0500 (EST) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 360901564A2 for ; Mon, 24 Jan 2011 16:07:22 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id 9N6kWXeYCBAs for ; Mon, 24 Jan 2011 16:07:20 +0100 (CET) X-KTH-Auth: kristaps [193.10.49.5] X-KTH-mail-from: kristaps@bsd.lv X-KTH-rcpt-to: discuss@mdocml.bsd.lv Received: from [172.16.18.84] (unknown [193.10.49.5]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 069841563C1 for ; Mon, 24 Jan 2011 16:07:16 +0100 (CET) Message-ID: <4D3D95A4.3070300@bsd.lv> Date: Mon, 24 Jan 2011 16:07:16 +0100 From: Kristaps Dzonsons User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Icedove/3.0.11 X-Mailinglist: mdocml-discuss Reply-To: discuss@mdocml.bsd.lv MIME-Version: 1.0 To: discuss@mdocml.bsd.lv Subject: Re: Bullets everywhere References: <20110110221110.GJ23329@acme.spoerlein.net> <20110123144048.GB4205@iris.usta.de> <20110123172251.GE65811@acme.spoerlein.net> In-Reply-To: <20110123172251.GE65811@acme.spoerlein.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 01/23/2011 06:22 PM, Ulrich Spoerlein wrote: > On Sun, 23.01.2011 at 15:40:48 +0100, Ingo Schwarze wrote: >> 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. > > Works for me. But there should be a small comment, explaining that this > is for groff compat and won't do much on xterms and Co. Please don't check this in: it causes assertions in -Tps and -Tpdf. Let me look into another solution, as passing raw escapes to the backend makes for unhappy backends. -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv