From: Kristaps Dzonsons <kristaps@bsd.lv>
To: Jason McIntyre <jmc@kerhand.co.uk>
Cc: "discuss@mdocml.bsd.lv" <discuss@mdocml.bsd.lv>
Subject: Re: .Li hiccup (and \*(Pu issue)
Date: Tue, 25 May 2010 22:42:33 +0200 [thread overview]
Message-ID: <4BFC3639.8030409@bsd.lv> (raw)
In-Reply-To: <20100525141839.GG8074@bramka.kerhand.co.uk>
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
next parent reply other threads:[~2010-05-25 20:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100525065543.GB8074@bramka.kerhand.co.uk>
[not found] ` <4BFBCEBB.4070205@bsd.lv>
[not found] ` <20100525141839.GG8074@bramka.kerhand.co.uk>
2010-05-25 20:42 ` Kristaps Dzonsons [this message]
2010-05-25 22:38 ` Jason McIntyre
2010-05-25 23:28 ` Ingo Schwarze
2010-05-26 0:49 ` Kristaps Dzonsons
2010-05-26 6:56 ` Jason McIntyre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BFC3639.8030409@bsd.lv \
--to=kristaps@bsd.lv \
--cc=discuss@mdocml.bsd.lv \
--cc=jmc@kerhand.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).