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

[Peter Schaffter]

Sorry, gang.  I sent this to Eric instead of to the list.

----- Forwarded message from Peter Schaffter <address@hidden> -----

Date: Wed, 5 Mar 2014 14:29:25 -0500
To: "Eric S. Raymond" <address@hidden>
From: Peter Schaffter <address@hidden>
Subject: Re: [Groff] Back to the future

On Tue, Mar 04, 2014, Eric S. Raymond wrote:
> Peter Schaffter <address@hidden>:
> >                Whether, or how, well-formed files and macrosets
> > should/could be xml/stylesheet-parsable in a semantic world has no
> > bearing on groff's future.  It's a front-end debate when back-end
> > development is what's needed.
> 
> But this I disagree with on multiple counts.
> 
> Firstly, front end and back end issues are *not* orthogonal, because
> nobody is ever going to design groff macros in a way that is totally
> decoupled from the capabilities of groff's back end. (And even
> intending to do that would be silly.)
> 
> Secondly, I think you can maintain this position only by taking an
> ahistorically narrow view of what 'groff' now is.  Like it or not, we
> remain responsible for supporting some important non-typesetting
> use cases - notably, man pages browsed through terminal emulators.

We absolutely do not disagree on the above items.  Occam's
Hatchet: I chopped *everything* away so we could look at the
cleanest bare bones.  Perhaps I didn't phrase my position clearly.
God knows, that's easy enough to do in email, even for a practised
writer.

I sensed that discussions about manpages/xml/etc were distracting
*at this stage, and at this stage only*.  You pointed out that
groff was getting close to life-support, so I applied basic First
Aid triage: breathing, bleeding, breaks, burns.  Breathing is the
backend (formatting engine, requests).  Bleeding is manpages.
Breaks is groff-in-an-xml-world.  Burns is real-number arithmetic,
order of operations, etc.  I hope my analogy isn't so stretched it
fails to make its point.  Basically, I was talking about trimming
away beclouding *debate* (again, only at this stage), not proposing
a future in which groff is impoverished by too narrow a focus.

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.

Damn, I hate it when I go on long, but something difficult to
quantify is also part of the groff picture. *roff is a system that
continues to perform in a backwardly-compatible manner practically
to its inception forty years ago.  If groff had a soul, that's
something it would be proud of.  It's resisted fashion without
becoming an obsolete.  It's a testament to, a proof of concept of,
the Unix philosophy and the hacker ethic in general.  Wherever groff
goes from here, I would never want to lose that.

> We can't simply abandon that job; it follows that we need to think about
> how to do it better, and - if you really want groff to narrow its scope
> to be a typesetting back end only - we need to think about how to hand
> off that job and what to hand it to. 
> 
> Fortunately for your vision, that is *precisely* what *I* have been doing...

I follow where you're going with your grand project, and support it
entirely.  Documentation for *nix is a subject of great concern to
me.  A little-known fact about the mom macros: from the start, the
project has been a test-bed for my theories about documentation:
content and style, presentation, usefulness, ease of use.  From the
start, it's been entirely html (converted later to xhtml).  I've
even resisted the urge to create a pdf version, which, it strikes
me, would be nothing more than showing off.  If that doesn't tell
you how closely we're aligned, nothing will. :)
 
> >           The manpages debate is largely about groff usage, not
> > groff development.
> 
> No. In the terms of argument you yourself have chosen, it's a debate
> about the design philosophy of front-end macros.  You are free to try
> to pretend that this is not an aspect of groff development if you like,
> but I am quite certain the rest of the world will not accommodate you in 
> this.

Again, we're on the same page.  As you point out, front and back end
issues are not orthogonal.  However, addressing front end issues
requires a slightly different approach from back end ones, hence
my wish to keep them separate--but only during the hammering out
process.

> > One shouldn't have to be a geek to benefit from the advantages,
> > which leads me to think that, ancillary to backend improvement,
> > there's a pressing need for groff advocacy.  Put another way, folks
> > need to know that using groff to format a novel isn't novel.  It's
> > pretty routine, and you shouldn't have to be a hacker to do it.
> 
> Me, I think this is a doomed enterprise. For this use case the rest of
> the world has moved on to DocBook, wiki-style markups, markdown, and
> asciidoc (that is, if they're not using a WP to begin with).  I can't
> see any reason at all it should look back.
> 
> If you want to preserve a role for groff, you need to start by being
> realistic about the range of use cases it's fit for in 2014 and going
> forwards.  Formatting of the general run of novels by casual users is
> not among then; that's *gone*, already lost to tools that play better
> with ePub.

This is a toughie, and it's where my beliefs, principles, standards,
and concerns for the future come into play--quite possibly in a
detrimental fashion, but maybe, just maybe, beneficially.  As early
a 2002, UNESCO issued a warning about the preservation of digital
data.  At the time, the paper focussed on preserving the equipment
necessary to read binary data, but it seemed evident to me that
preserving content was the more important goal, hence the immense
importance of formatting systems that take plain text files as
input.  Groff is one such system, and while it may be a finger-in-
the-dike, it's worth remembering that that finger, in Mary Dodge's
story, prevents Holland from being inundated.

I say this because you are quite right: the use case for groff by
writers of non-technical works--who, for the purposes of simplicity,
I refer to as "prose writers"--is practically nil.  A situation
unlikely to change if groff remains, in the general imagination, a
geeks-only tool.

The enterprise may be doomed, but I'm not one to abandon ship just
because the rats are fleeing.

> > Why do I care?  Well, with the greatest of respect to Eric, I
> > feel that "the page", as it has been recognized for centuries,
> > is far, far from being irrelevant to the future of material
> > intended to be read at the screen.
>
> I think we'll just have to disagree on this.  You sound to me like
> a Babylonian scribe arguing that reading won't be *right* without
> the feel of the clay tablet in the reader's hands.

No, nothing like that at all.  My position, and the arguments I
bring to bear on it, are more nuanced.  But I understand how you
could mistake me for an "I just like the feel of a good book in my
hands" type of guy.  I'm sure I come across that way.  Truth is,
I've been promoting "good type on the screen" for years.

> 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.
 
> 5. Improve the semantic expressiveness of man markup.

Hallelujah!
 
> 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_.)
 
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 am not sufficiently adept
at the coding and administrative skills required.  If I may use
an analogy, I'd be like a conductor who knows that an orchestral
passage requires perfectly synchronized pizzicato but hasn't the
violin chops needed to coax it from the players.

The project needs a conductor, it's true (reference to Werner's
meat-world profession unintended), but it needs a concert master,
too, a person or corpus capable of implementing the details--ie the
coding--of the larger vision.  Without that, it's all talk and no
walk.

----- End forwarded message -----

-- 
Peter Schaffter
http://www.schaffter.ca