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

[Eric S. Raymond]

Peter Schaffter <address@hidden>:
> For the record, I feel that groff's evolution, if it is to happen,
> should be practically invisible in terms of user deployment.
> Whatever worked should continue to work, just better.  I propose an
> improved groff, not a new one.  It's why I'm increasingly dead-set
> against forking.  There is simply no need.

I agree about the absence of any need for forking.

I almost completely agree about the 100% backward compatibility, with
one significant exception.  I am now contemplating a future in which
simplifying and regularizing man markup in the semanticized direction
I think it needs to go *will* cause some compatibility breakage.

There won't be a lot, but the worst problems will be concentrated in
an awkward way - in groff itself, in other GNU projects, and in other
old and large projects with a lot of historical inertia and
prestige. The common denominator in the handful of problem children
will be use of a more troff-aware markup style dating from when people
routinely ... printed out ... documentation.

It's going to take some PR and battlespace preparation before we can
do this without causing a massive political shitstorm.  But before we
can do *that* we need to be sure of our technical ground - which is
why: 

(1) the first blocker on my agenda is a decent design for
information-hiding (e.g. hygienic mode).

(2) The second item is a field study in in which I experiment with
successively more severe hygienic restrictions on the manual tree of
an entire Linux distribution to see how much stuff breaks at each
level.

I can pretty much guarantee no more than 6% breakage in the worst
case, but I think even that much is too high to be acceptable.  I'm
prepared to fight the political fight for up to 3% breakage, and we're
lucky there will be an obvious knee in the curve somewhere below
that. I wouldn't actually be surprised  if it were < 1%.

I don't have time to do this yet.  Among other things I need to finish
the Emacs repo cleanup first.  But I've been quietly working the larger
problem this is part of for ten years - I'm not going to go away.

> I follow where you're going with your grand project, and support it
> entirely. 

OK, that will help.

> > 4. Identify 'semantic' macro packages, including man markup and possibly 
> > mom.
> > Work towards systematically isolating those macro sets from groff-specific 
> > back end details, with the general direction of making them more semantic
> > and enabling simpler non-groff rendering engines for terminal and web use.
> 
> Yes, yes, and yes.

It is useful to know that you do consider mom to fall in this category.

> > 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....

> > I'm willing to work on these things, not just talk about them.  To
> > be more concrete, I'm willing to own the cluster of design and
> > implementation problems around man macros.
> 
> Speaking for myself, I welcome this.  It puts you in charge of an
> important component of your larger documentation vision.  What do
> others think?  (Actually, it's beginning to look as if this is a
> _fait accompli_.)

I don't see anybody else stepping up.

> Now, on to the final issue...
> 
> > All hail the new project leader! :-)
> 
> My recent contributions to the list haven't been a bid to take on
> that role, however they might read. 

I know.  I was having a bit of fun at the expense of your reluctance.
But it was a ha-ha-only-serious.  If not you, who?  If not now, when?
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>