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 o63HShfL006290 for ; Sat, 3 Jul 2010 13:28:44 -0400 (EDT) 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 1OV6WA-00086X-Jt; Sat, 03 Jul 2010 19:28:42 +0200 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.71) (envelope-from ) id 1OV6WA-0007rn-G5 for discuss@mdocml.bsd.lv; Sat, 03 Jul 2010 19:28:42 +0200 Received: from iris.usta.de ([172.24.96.5] helo=usta.de) by donnerwolke.usta.de with esmtp (Exim 4.69) (envelope-from ) id 1OV6WA-0005q3-FH for discuss@mdocml.bsd.lv; Sat, 03 Jul 2010 19:28:42 +0200 Received: from schwarze by usta.de with local (Exim 4.71) (envelope-from ) id 1OV6WA-0005jB-EN for discuss@mdocml.bsd.lv; Sat, 03 Jul 2010 19:28:42 +0200 Date: Sat, 3 Jul 2010 19:28:42 +0200 From: Ingo Schwarze To: discuss@mdocml.bsd.lv Subject: Re: desired .Bk semantics? Message-ID: <20100703172842.GE4327@iris.usta.de> References: <20100702234320.GC6026@iris.usta.de> <20100703065442.GA5970@bramka.kerhand.co.uk> <4C2F2CA9.2030209@bsd.lv> <20100703141126.GB20174@bramka.kerhand.co.uk> <4C2F644F.3070307@bsd.lv> X-Mailinglist: mdocml-discuss Reply-To: discuss@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C2F644F.3070307@bsd.lv> User-Agent: Mutt/1.5.20 (2009-06-14) Hi Kristaps, Kristaps Dzonsons wrote on Sat, Jul 03, 2010 at 06:24:47PM +0200: > I propose the following. I've enclosed a patch that demonstrates this. > First, I disabled `Bk' completely. I disagree: That is going too far. Like that, you lose the possibility to keep non-optional arguments together on the same line. Consider, e.g. .Nm cut .Bk -words .Fl b Ar list .Ek .Op Ar n .Op Ar .Nm cut .Bk -words .Fl c Ar list .Ek .Ar I admit in this case this is not critical because the keep is near the beginning of the line, but this is how it should be written, and such necessities can also arise later on the line, Thus, do not rip .Bk out completely. It should be available for the rare cases where is is needed, and it is a standard mdoc(7) macro we cannot just drop. > Second, when `Op' or `Oo' is encountered with MDOC_SYNPRETTY (i.e., in a > SYNOPSIS section or with ".nr nS 1"), spaces are made non-breaking. I disagree: That is going too far. Like that, you lose the option to allow breaking in the middle of an .Op or .Oo group. Consider, e.g. .Nm openssl .Cm gendsa .Oo .Fl aes128 | .Fl aes192 | .Fl aes256 | .Fl des | .Fl des3 .Oc ... This could get worse when more ciphers are implemented, and ultimately, it won't fit on one line any more, giving you very ugly output and no way to fix it. I don't oppose automatically assuming implied .Bk around .Op and .Oo tough, as long as they are on one input line, even though troff historically decided against that. That's probably the last mail i can send before teardown of the hack room, and i don't have time to look at your code right now... Yours, Ingo -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv