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: Peter Schaffter
Subject: Re: [Groff] address@hidden: Re: Back to the future]
Date: Wed, 5 Mar 2014 21:00:27 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Mar 05, 2014, Eric S. Raymond wrote:
> Peter Schaffter <address@hidden>:
> 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.

You're proposing a future in which we strive our utmost not to break
anything, while at the same time acknowledging that a few cracks
might show up while the overall structure settles.  This is normal
in the development of an evolving program.

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.

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

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

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

I do.  I won't get into why here.  Last fall, at the suggestion of a
user, I prepared a document, _Groff and Mom: An Overiew_, which
makes the case, I think.  I've posted it at

  http://www.schaffter.ca/shared/groff-and-mom.pdf

The Appendix discusses both the stylesheet file and the marked-up
source.  They're at

  http://www.schaffter.ca/shared/groff-and-mom-style.mom
  http://www.schaffter.ca/shared/groff-and-mom.mom

As an aside, the document is still a draft, so I wouldn't mind
several extra pairs of eyes giving it a going over.

> > > 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.
 
-- 
Peter Schaffter
http://www.schaffter.ca



reply via email to

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