Pierre-Jean <li...@utroff.org>:
> > Actively supporting is empty verbiage unless you have a mechanical
> > translator from man(7) markup to semantically enriched mdoc(7). You
> > don't, and I know exactly why you don't, because I wrote the pattern
> > analyzer you would need and don't have.
>
> Eric is wright: if doclifter could evolve to produce mdoc
> document from man document, most of the semantic man problem
> would be solved. Adapting doclifter in such a way could be a
> great occasion to define in which point mdoc would have to
> be improved.
>
> Eric knows the solution and is the most competent person to
> implement it. It would be a great gift to the community if
> he would agree to do the job. It would also be a great
> example of community conciliation.
I fear you don't fully understand what you are asking me to do.
It would be neither practical nor useful.
It would be impractical for several technical reasons. One is because
doclifter doesn't have parsing separated from XML generation in such a way
as to allow retargeting the back end. It doesn't really have a "back end"
at all; the strategy it uses is more like successive incremental text
rewrites.
(I am sure some people will react to this revelation with "You should
have written a proper parser! Shame on you!" They'd have a point if the
input language were a context-free grammar - alas, it is not. It is much
messier than that.)
I also judge it also wouldn't be useful. Remember the mission: clean
manual-page rendering to multiple output media, including HTML and
printers. man(7) to doclifter to a stylesheet already gives me that;
there's nothing to be gained by detouring through mdoc(7) on the way.
I have too much other work to do to tear apart doclifter and completely
rebuild it for the sole sake of "community conciliation". Besides, if
I tried, I'd probably break it irreparably. That code is *complex*.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
