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 oBLN028U014698 for ; Tue, 21 Dec 2010 18:00:04 -0500 (EST) 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 1PVBBX-00070q-0C; Tue, 21 Dec 2010 23:59:59 +0100 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.72) (envelope-from ) id 1PVBBW-0004vR-Ut for tech@mdocml.bsd.lv; Tue, 21 Dec 2010 23:59:58 +0100 Received: from iris.usta.de ([172.24.96.5] helo=usta.de) by donnerwolke.usta.de with esmtp (Exim 4.69) (envelope-from ) id 1PVBBW-0006aa-TS for tech@mdocml.bsd.lv; Tue, 21 Dec 2010 23:59:58 +0100 Received: from schwarze by usta.de with local (Exim 4.72) (envelope-from ) id 1PVBBW-00058k-KG for tech@mdocml.bsd.lv; Tue, 21 Dec 2010 23:59:58 +0100 Date: Tue, 21 Dec 2010 23:59:58 +0100 From: Ingo Schwarze To: tech@mdocml.bsd.lv Subject: Re: mdocml: Add a "last child" member of struct mdoc_node. Message-ID: <20101221225958.GA9705@iris.usta.de> References: <201012152339.oBFNdeuH023314@krisdoz.my.domain> X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201012152339.oBFNdeuH023314@krisdoz.my.domain> User-Agent: Mutt/1.5.21 (2010-09-15) Hi Kristaps, > Add a "last child" member of struct mdoc_node. > Remove `Pp' or `Lp' if it is the FIRST or LAST child of an `Sh' or `Sh' body. Keeping track of the last child looks nice, ... > Make "skipping paragraph" be an error, not a warning, as information (an > invoked macro) is ignored. ... but i disagree with this part. When we say, in mandoc(1), error An input file contains syntax that cannot be safely interpreted, either because it is invalid or because mandoc does not implement it yet. By discarding part of the input or inserting missing tokens, the parser is able to continue, and the error does not prevent generation of formatted output, but typically, preparing that output involves information loss, broken document structure or unintended formatting. i think the most important part is the first line: *cannot be safely interpreted* The wording at the end, *information loss*, is not a definition, but rather an example. In any case, we are not talking about information in the mathematical sense here, but about information that matters to the user, information that, when being lost, could cause the user to misunderstand the content of the manual. So, i would consider anything that might cause loss of a blank line, or insertion of one in excess, to be safe. Also, this distinction is not academical, but it has practical consequences. I'm telling people that, as long as there are errors, they should use groff to format the manual. I'm telling them that errors are what gives them broken manuals, with wrong content or unintelligible formatting, for porters to worry about; while warnings only means unclean source code, with no serious impact on manual content, merely for authors to worry about, in case they care about nice mdoc(7) usage. Here, we clearly have the second case, a warning, not an error. Yours, Ingo P.S. See here for the full story: http://www.openbsd.org/faq/ports/specialtopics.html#Mandoc -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv