From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by krisdoz.my.domain (8.14.3/8.14.3) with ESMTP id o4PKgjf5013828 for ; Tue, 25 May 2010 14:42:46 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id CEC0A14DCA2; Tue, 25 May 2010 22:42:39 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([127.0.0.1]) by localhost (smtp-2.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qsC0GhTPt4GY; Tue, 25 May 2010 22:42:38 +0200 (CEST) X-KTH-Auth: kristaps [85.8.61.146] X-KTH-mail-from: kristaps@bsd.lv Received: from lappy.bsd.lv (h85-8-61-146.dynamic.se.alltele.net [85.8.61.146]) by smtp-2.sys.kth.se (Postfix) with ESMTP id AED4B14DCA1; Tue, 25 May 2010 22:42:34 +0200 (CEST) Message-ID: <4BFC3639.8030409@bsd.lv> Date: Tue, 25 May 2010 22:42:33 +0200 From: Kristaps Dzonsons User-Agent: Thunderbird 2.0.0.16 (X11/20080812) X-Mailinglist: mdocml-discuss Reply-To: discuss@mdocml.bsd.lv MIME-Version: 1.0 To: Jason McIntyre CC: "discuss@mdocml.bsd.lv" Subject: Re: .Li hiccup (and \*(Pu issue) References: <20100525065543.GB8074@bramka.kerhand.co.uk> <4BFBCEBB.4070205@bsd.lv> <20100525141839.GG8074@bramka.kerhand.co.uk> In-Reply-To: <20100525141839.GG8074@bramka.kerhand.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Note this is being posted into the discuss list. Reads in a standard bottom-posted way, for newcomers (jmc first, then me, then jmc). >>> hi. found a blip whereby Li seems to be doing something weird. from >>> expr.1: >>> >>> .It Ar expr1 Li : Ar expr2 >>> >>> groff: expr1 : expr2 >>> mandoc: expr1: expr2 >>> >>> to be honest, Li is treating the colon as punctuation, and i'd kind of >>> expect that. but groff does not. so i'm not sure what way you want to >>> go. >> >> Seems this can be generalised: in-line macros treat closing punctuation >> differently when it's used as the first term; namely, the treat it like >> a normal word. So >> >> .Fl . a b >> >> becomes >> >> -. -a -b >> >> while >> >> .Fl a . b c >> >> becomes >> >> -a. -b -c >> >> I've come to have a rule of thumb: if we can't explain something in a >> single mdoc.7 sentence, we shouldn't be following it. I have no idea >> how to explain this, so I think it should go into CAVEATS as crappy >> behaviour we don't emulate. >> >> If you think otherwise, please let me know; I know where this behaviour >> can be "fixed" in mdoc_macro.c. Until then, I note that it already >> exists in Ingo's TODO: >> >> http://mdocml.bsd.lv/cgi-bin/cvsweb/TODO?cvsroot=mdocml > > well, i'm not sure. i can see reasons for and against. nothing is > documented in mdoc.samples.7 really. it just says that macros can handle > punctuation. but given that this would be an exception, and that the > behaviour does not conform with groff, i'd be tempted to say we'd be > better off emulating it. if not, i guess we need to document it clearly. > > i'm not too fussed though. i can change the page if you think it better > to keep current behaviour. I respectively suggest, in this case, that the invocations be fixed. I think that people have confused `Li' as meaning "what follows is interpreted in literal mode", instead of "is rendered in a fixed font", as this behaviour is only used for `Li' and not for any other macro, to wit (on OpenBSD): % egrep 'Li [:.;] ' `cat manuals.txt ` usr.sbin/bgpd/bgpd.conf.5:.Ar as-number Ns Li : Ns Ar local , usr.sbin/bgpd/bgpd.conf.5:.Ar subtype Ar as-number Ns Li : Ns Ar local usr.sbin/bgpd/bgpd.conf.5:.Ar subtype Ar IP Ns Li : Ns Ar local usr.sbin/bgpd/bgpd.conf.5:.Ar as-number Ns Li : Ns Ar local usr.sbin/bgpd/bgpd.conf.5:.Ar as-number Ns Li : Ns Ar local , usr.sbin/bgpd/bgpd.conf.5:.Ar subtype Ar as-number Ns Li : Ns Ar local usr.sbin/bgpd/bgpd.conf.5:.Ar subtype Ar IP Ns Li : Ns Ar local usr.sbin/bgpd/bgpd.conf.5:.Ar as-number Ns Li : Ns Ar local . usr.sbin/bgpd/bgpd.conf.5:.Ar IP Ns Li : Ns Ar local . bin/expr/expr.1:.It Ar expr1 Li : Ar expr2 usr.bin/login/login.1:.Li : Ns Va style usr.bin/login/login.1:.Ar user Ns Li : Ns Va style ) . Except for expr.1, these are actually trying to fix groff's behaviour of the extra space! So expr.1 is the only one that actually depends on this crappy behaviour. > oh, and while looking at this, i see another issue - we now have no > \*(Pu sequence for characters considered punctuation. at least > mdoc.samples.7 uses this (probably nothing else). new groff does not > recognise it, and its current equivalent man page, groff_mdoc.7 simply > lists the punctuation characters. i'm guessing you won;t see a need to > add the sequence, so should i just adjust our page? We can temporarily define a chars.in for \*(Pu, but only mdoc.samples.7 in NetBSD and OpenBSD use this (NB, I don't know where FreeBSD's mdoc.samples.7 is to look at it, but a grep over all the source can't find the invocation). Once our mdoc.7 replaces mdoc.samples.7, this won't be an issue. I suggest having a downstream chars.in patch for it, as I don't want to put it in upstream and have people assume that it exists. Then once mdoc.7 takes over mdoc.samples.7, it can be removed. Thoughts? Kristaps -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv