Re: -Tman with -mman

[Ingo Schwarze <schwarze@usta.de>]

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.

Yours,
  Ingo
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv