From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from scc-mailout.scc.kit.edu (scc-mailout.scc.kit.edu [129.13.185.202]) by krisdoz.my.domain (8.14.3/8.14.3) with ESMTP id pB415ffM019812 for ; Sat, 3 Dec 2011 20:05:41 -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 1RX0WS-0000FI-E4; Sun, 04 Dec 2011 02:05:40 +0100 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.72) (envelope-from ) id 1RX0WS-0006go-Bz for tech@mdocml.bsd.lv; Sun, 04 Dec 2011 02:05:40 +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 1RX0WS-0006a2-9T for tech@mdocml.bsd.lv; Sun, 04 Dec 2011 02:05:40 +0100 Received: from schwarze by usta.de with local (Exim 4.72) (envelope-from ) id 1RX0WS-0004CP-8W for tech@mdocml.bsd.lv; Sun, 04 Dec 2011 02:05:40 +0100 Date: Sun, 4 Dec 2011 02:05:40 +0100 From: Ingo Schwarze To: tech@mdocml.bsd.lv Subject: Re: remove .Xr spacing tweak Message-ID: <20111204010540.GO17667@iris.usta.de> References: <20111203181634.GF17667@iris.usta.de> <4EDA9839.9050001@bsd.lv> X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EDA9839.9050001@bsd.lv> User-Agent: Mutt/1.5.21 (2010-09-15) Hi Kristaps, Kristaps Dzonsons wrote on Sat, Dec 03, 2011 at 10:44:25PM +0100: > On 03/12/2011 19:16, Ingo Schwarze wrote: >>i think it is time to remove an OpenBSD-specific tweak from the .Xr >>handling in OpenBSD mandoc(1) and make it compatible with bsd.lv >>mandoc and with groff-1.21. >>Right now, OpenBSD assumes an implicit .Ns after .Xr's second >>argument, if more non-punctuation arguments follow. >> >>This tweak in mdoc_macro.c was originally added for compatibility >>with groff-1.15, which is now gone for some time. >> >>The patch also scours the base tree, adapting those pages where >>the rendering would change. > Of course this is fine by me -- the code is #ifdef'd in my repo > anyway. It's always a pleasure to remove code bearing an XXX comment to the effect that it is ugly and unlikely to go away. :-) > Does this warrant a COMPATIBILITY note, as it relates to > old groff behaviour? I don't think so. Ten-year old groff added an additional blank character to the output if some macro was called with more arguments than it normally supports; nobody was sure why, it seemed a bit illogical. Maybe it was a bug, but anyway, it was fixed in groff half a decade ago. That sounds quite silly in a manual, doesn't it? There is no need to document every single ancient groff idiosyncrasy, that would just bloat the documentation. Of course it's always a matter of judgement, i think clear rules are hard to find for deciding what warrants mention below COMPATIBILITY. Roughly, i'd say that * Recent changes are more important than ancient bugs. * Groff/mandoc differences are more important than new/old groff differences. * Parser incompatibilities are more important than rendering differences. * Text differences are more important than whitespace differences. Very roughly, i'd maybe say that we should mention it if it's recent OR affects the parsers OR may affect the content. Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv