groff
[Top][All Lists]
Advanced

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

Re: [Groff] address@hidden: Re: Back to the future]


From: Eric S. Raymond
Subject: Re: [Groff] address@hidden: Re: Back to the future]
Date: Wed, 5 Mar 2014 22:32:35 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

Peter Schaffter <address@hidden>:
> As you point out in your DocLifter post, the actual number of groff
> requests needed for xml-friendly and presentationally-acceptable
> markup is very limited.  I suspect list members who've spoken out
> against your proprosals are imagining some sort of mighty overhaul
> that will leave groff, in its role as a documentation formatter,
> unrecognizable.  Correct me if I'm wrong, but that is not your
> intention.  Not by a long shot.

Oh, *hell*, no.  And never was.  Doubting that a printer-only formatter
is interesting in 2014 does not mean I want to change it massively.
I mean, why would I bother?  I've already got asciidoc and DocBook. 

Here's my entire program as I now envision it:

1. Design and implement hygienic mode.

2. Use that to narrow the interface between the man macros and groff.

3. Extend man macros in the direction of richer semantic markup.

> > It's going to take some PR and battlespace preparation before we can
> > do this without causing a massive political shitstorm.
> 
> Yes, I can smell a storm a-comin'.  IMO, whatever PR work needs to
> be done must focus on reassuring nay-sayers that your proposals
> aren't of the "Oh, god, everything's going to break and I'll have to
> rewrite all my documentation" variety.

Quite :-)

> I cannot see how this could do any harm, and a field study, if it
> returns the results you hope for, would go a very long way to
> speeding up acceptance and adoption of the magnum opus.

You may assume that I considered the political uses of being able
to trot out those statistics on demand right along with the technical
benefits of gathering them.

> > > > 5. Improve the semantic expressiveness of man markup.
> > > 
> > > Hallelujah!
> > 
> > Yeah, that's going to be an *interesting* design and deployment problem.
> > Deployment more difficult than design....
> 
> Not sure why you think deployment will be more difficult than design
> unless you are, in fact, proposing more radical changes than I
> believe.  Please explain.

Mainly because of the long deployment cycles on distributions.

Designing a good set of extensions is all very well, but I figure
it'll be a dead minimum of two years from first ship before they
become ubiquitous enough for authors to consider them portable.  The
challenge will be timing the release and lobbying the distros so it isn't
three years. Or five :-(.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>



reply via email to

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