From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by krisdoz.my.domain (8.14.3/8.14.3) with ESMTP id p93MJ2k4013727 for ; Mon, 3 Oct 2011 18:19:02 -0400 (EDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id E2C4E1563A0; Tue, 4 Oct 2011 00:18:56 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id YfNPZBahx9KC; Tue, 4 Oct 2011 00:18:55 +0200 (CEST) X-KTH-Auth: kristaps [93.158.36.21] X-KTH-mail-from: kristaps@bsd.lv Received: from macky.local (unknown [93.158.36.21]) by smtp-1.sys.kth.se (Postfix) with ESMTP id DE0141557D3; Tue, 4 Oct 2011 00:18:53 +0200 (CEST) Message-ID: <4E8A34CC.70706@bsd.lv> Date: Mon, 03 Oct 2011 23:18:52 +0100 From: Kristaps Dzonsons User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 To: tech@mdocml.bsd.lv CC: Ingo Schwarze Subject: Re: -Tman with -mman References: <4E887D72.9090605@bsd.lv> <20111002154058.GA14208@britannica.bec.de> <4E88C13D.6090708@bsd.lv> <20111003220029.GG20053@iris.usta.de> In-Reply-To: <20111003220029.GG20053@iris.usta.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 03/10/2011 23:00, Ingo Schwarze wrote: > Hi Kristaps, > > Kristaps Dzonsons wrote on Sun, Oct 02, 2011 at 09:53:33PM +0200: >> On 02/10/2011 17:40, Joerg Sonnenberger wrote: >>> On Sun, Oct 02, 2011 at 05:04:18PM +0200, Kristaps Dzonsons wrote: > >>>> What sort of behaviour is most reasonable when providing a man >>>> manual to the new -Tman? I think this should be ironed out before >>>> the release. The mandoc manual says "-Tman only with mdoc" and, if >>>> man is provided to -Tman, outputs nothing (like -Tlint). >>>> >>>> It makes the most sense to me to output the original file (after >>>> preprocessing, I guess). All this requires is a duplicate buffer in >>>> read.c (conditional on -Tman being present to avoid overhead in >>>> normal usage). I don't like the idea of putting out an error (or >>>> nothing at all) because it special-cases modes for input. > >>> Agreed, just giving back the original input (maybe reformatted) sounds >>> like the best approach. > > I agree that makes sense if the code is parsed (.man -> AST) > and then freshly formatted (AST -> .man) in the sense of a validating, > normalizing parser. > > Oops, now that i think about it, maybe i went the wrong way with > mdoc -> man? Maybe i should have implemented that as a two-step > translation? First mdoc-AST -> man-AST, then man-AST -> man-code? > Maybe i should start over? Hm... > >> Putting some code to the idea... > > Not that i'm really opposed to your small patch - but i'm not > sure this is terribly useful either, so far it's mostly > a fancy cat(1). > > In case we maybe want to implement a real normalizing parser later, > i'm both OK with erroring out until we get there or putting in > your fancy cat(1). > >> (Sorry for the churn, I ordered the >> mandoc.h functions. They're the same except for the mandoc_keep() >> and mandoc_getkeep() additions). This isn't quite commit-ready, but >> a start. Basically, I ask for a keep buffer if OUTT_MAN is >> specified. This needed some machinery to expose the parser to the >> front-end. >> >> Thoughts? > > Well, as a placeholder for something better later, the general > idea seems OK. Ingo, I think the approach you have is fine---since I don't foresee this mode as being heavily used, let's keep it as small as possible. I think adding normalised-output modes to mandoc is just bloat. Meanwhile, I'll put in the fancy-cat. This fits my expectation of an output mode always producing output. (It also doesn't cost anything.) Incidentally, the docs need to be updated to note that the `so' invocations are resolved prior to output and the roff in mdoc input is stripped. This may not be expected behaviour, so... Thanks, Kristaps -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv