Ingo Schwarze <schwa...@usta.de>:
> Actually, there are four questions that are somewhat separate
> but also influence each other a bit:
>
> (1) What are we to do with man(7)?
> Eric proposes to carefully evolve it to introduce a small amount
> of semantic markup.
> I propose to provide continuing support for backward compatibility
> and refrain from adding new features.
>
> (2) What are we to do with mdoc(7)?
> I propose to carefully maintain and polish it, of course without
> any substantial upheaval.
> If i understand Eric correctly, he is largely indifferent
> regarding mdoc(7).
>
> (3) What is our recommendation for manual writers, right now?
> I propose to tell them: If they want semantic markup right
> now, they can switch to mdoc(7), lightweight tools are ready
> for use.
> If i understand Eric correctly, he is telling them to
> continue writing their manuals with purely presentational
> man(7) markup for now and just rely on doclifter.
>
> (4) What is our vision for manual markup in, say, five years?
> Eric says, tell people to use new man-ext(7) features to be
> developed in the meantime.
> I say, just the same as today. If people don't care that much
> about semantic markup or don't mind heavy toolchains, they can
> leave their existing stuff in man(7) and use doclifter. If
> they do care, they can switch to mdoc(7) and use much simpler
> tools, just as today.
I'm quoting this to confirm that it is a fair summary of my position.
A few minor amendments:
1. I am at least as interested in narrowing and simplifying the man markup
language (decoupling it from groff peculiarities) as I am in extending it.
2. What's in man_ext now may be enough extension already. I'm more
inclined to think that than I was last week,
3. Wearing my "person who has to cope with interpreting it" hat, mdoc(7)
annoys the crap out if me. But it is fair to say I am indifferent about its
future relationship with groff.
> What are the consequences of implementing Eric's plan regarding (1)?
>
> (1a) Whatever we do in groff_man(7), i have to re-implement it
> in mandoc(1). That will burn some of my time, and i don't
> relish the idea, but it's not a huge problem for me, either.
> mandoc(1) already supports a couple of man-ext(7) macros,
> .EX .EE .OP .UR .UE. Only .MT .ME .SY .YS .TQ are missing,
> simply because i never encountered them in any real-world
> manual so far. Usually, macros of Eric's design have been
> very easy to implement; well, .SY may be slightly tricky,
> but not that much worse than .TP, i guess.
It is not an accident that they're easy to implement. I wanted them
to be easy to understand.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
