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 o5RIE4k3007751 for ; Sun, 27 Jun 2010 14:14:05 -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 1OSwMk-00017h-UT; Sun, 27 Jun 2010 20:14:03 +0200 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.71) (envelope-from ) id 1OSwMk-0001RA-TJ for discuss@mdocml.bsd.lv; Sun, 27 Jun 2010 20:14:02 +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 1OSwMk-00028l-SZ for discuss@mdocml.bsd.lv; Sun, 27 Jun 2010 20:14:02 +0200 Received: from schwarze by usta.de with local (Exim 4.71) (envelope-from ) id 1OSwMk-0002Nx-RW for discuss@mdocml.bsd.lv; Sun, 27 Jun 2010 20:14:02 +0200 Date: Sun, 27 Jun 2010 20:14:02 +0200 From: Ingo Schwarze To: discuss@mdocml.bsd.lv Subject: Re: Basic implementation of .Bk/.Ek Message-ID: <20100627181402.GL19398@iris.usta.de> References: <20100627174453.GK19398@iris.usta.de> 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: <20100627174453.GK19398@iris.usta.de> User-Agent: Mutt/1.5.20 (2009-06-14) Hi Jason, > i'll request this again, publicly: Bk/Ek makes no sense for synopsis. I tend to agree: We do need a .Bk implementation even for the SYNOPSIS to deal with existing pages, but always writing stuff like .Bk -words .Op o Ar file .Ek for each and every single argument is positively tedious, and figuring out for which argument it is needed because it will end up near the end of the line is tedious, too, fragile when adding arguments, and finally broken now that we have -Owidth=width. [...] > what i'd like, though i have no idea if it's practical: > mandoc recognises these macros but ignores them completely. I think when present, they should be honoured, even in the SYNOPSIS. > instead, it always formats SYNOPSIS in a way which causes no line > break in the wrong place. is that a possibility? I suspect we will be able to identify a couple of cases that basically always want to be wrapped in .Bk inside the SYNOPSIS, and make that automatic. For example, the following cases come to mind: * We probably never want a line break in the middle of .Op or between .Oo and .Oc. * We probably never want a line break between .Fl and immediately following .Ar. The trick is to unambiguously describe these cases and not just resort to "do not break where it looks ugly" because that's kind of hard to implement. :) I should like attacking that task after fixing more of the outright bugs still keeping us company. By the way, decent .Bk support is now committed both to bsd.lv and openbsd.org. Yours, Ingo -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv