Peter Schaffter <pe...@schaffter.ca>:
> 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>
