From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailout.scc.kit.edu (mailout.scc.kit.edu [129.13.185.202]) by krisdoz.my.domain (8.14.5/8.14.5) with ESMTP id s2VGDI6F016239 for ; Mon, 31 Mar 2014 12:13:19 -0400 (EDT) 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 1WUepn-0008BD-UE; Mon, 31 Mar 2014 18:13:15 +0200 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1WUepn-0003fy-SY; Mon, 31 Mar 2014 18:13:15 +0200 Received: from iris.usta.de ([172.24.96.5] helo=usta.de) by donnerwolke.usta.de with esmtp (Exim 4.72) (envelope-from ) id 1WUepn-0003KJ-Sw; Mon, 31 Mar 2014 18:13:15 +0200 Received: from schwarze by usta.de with local (Exim 4.77) (envelope-from ) id 1WUepn-0007h2-H2; Mon, 31 Mar 2014 18:13:15 +0200 Date: Mon, 31 Mar 2014 18:13:15 +0200 From: Ingo Schwarze To: Kristaps Dzonsons Cc: discuss@mdocml.bsd.lv Subject: Re: pod2mdoc, docbook2mdoc Message-ID: <20140331161315.GC31866@iris.usta.de> References: <53386109.9000504@bsd.lv> <20140331090912.GW26456@danbala.tuwien.ac.at> <533943B9.5080901@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: <533943B9.5080901@bsd.lv> User-Agent: Mutt/1.5.21 (2010-09-15) Hi Kristaps, Kristaps Dzonsons wrote on Mon, Mar 31, 2014 at 12:30:17PM +0200: > Thank you for doing this! Though I worry... is this not moving too > fast? These tools are fresh--real fresh--and moving fast. Is it not > too soon for committing to a port? I wouldn't worry too much about that. The version number 0.0.5 is telling enough, and the package description can say a few words too. So i see no big risk there, but possible benefit allowing cleaner packaging, installation and deinstallation of experimental tools. > pod2mdoc works over all the POD > I found (not being a Perl junkie, however, I just used what's in the > Perl distribution), but docbook2mdoc still needs a lot of work. Indeed. As far as i can see, the biggest problem right now is that it usually exits in the middle of each processed file, rendering merely the beginning. To be usable, it has to become more resilient. At first sight, it seems that the "ps->stop = 1;" in the function xml_elem_start() cause the problem, but i didn't try to come up with a fix yet. cvs.1.xml:33:6: unknown node "indexterm" lynx.1.xml:83:0: unknown node "literallayout" sqlite3.1.xml:108:0: unknown node "markup" > Fact is, I just don't know the "real world" landscape of ports using > docbook (or POD, for that matter). Would it not be better to have > somebody using (or porting) POD or DocBook systems to break them in > before putting them out for general consumption? Thoughts? A good corpus of test input would be the man(7) manuals in OpenBSD base, imho. As far as these are POD input, they are good testing candidates for pod2mdoc; i consider the test chain POD -> pod2man -> man(7) -> doclifter -> DocBook-XML -> docbook2mdoc mostly useless. As far as they are real man(7), not from POD, they are good testing candidates for docbook2mdoc, i.e. using the testing chain man(7) -> doclifter -> DocBook-XML -> docbook2mdoc -> mdoc(7). At least at first, i think the main use for docbook2mdoc will be as a postprocessor for doclifter, so getting it to handle the subset of DocBook-XML produced by doclifter is the second most useful step to take after preventing it from exiting prematurely (see above). In any case, docbook2mdoc seems much more useful than pod2mdoc, at least in a short-term perspective. Yours, Ingo -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv