groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Mission statement, second draft


From: Eric S. Raymond
Subject: Re: [Groff] Mission statement, second draft
Date: Tue, 18 Mar 2014 18:27:17 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

Ingo Schwarze <address@hidden>:
> 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>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]