Re: [Groff] Back to the future

[Ingo Schwarze]

Hi Peter,

Peter Schaffter wrote on Mon, Mar 03, 2014 at 04:43:27PM -0500:

> if we're to figure out what to do about groff in the future,
> we're going to have to stick to the big picture.

Actually, as long as there is nobody who has the time and interest
and skills to actually do some groff C++ coding, figuring out those
questions is not exactly urgent, we can take our time.  Chatting
about it does not do much harm either (except consuming time), but
is not going to change anything unless somebody tackles the work.
And *if* somebody, or a few people, turn up who have the time and
interest and skills, they are likely the restart that discussion
anyway, because, well, they have the *interest* and it's not likely
they will be indifferent regarding *what* they will code...

I think in one respect, Peter and Eric miss each other's point.
When Peter talks about a "technical lead", he talks about a lead
developer, a lead coder.  I have no idea whether Peter could or
would do that, but he himself seems a bit hesitant, to say the
least.  When Eric talks about a "technical lead", he talks about a
discussion leader, a moderator, helping a pack of twenty hot-tempered
developers to find a consistent vision and jointly move on the cart
into that consistent direction, instead of constantly stomping on
each other's toes.  The risk of stomping, right now, seems somewhat
limited.

So, regarding the breathing, we are currently helpness, the patient
is in coma, and the discussion what a good physician might attempt
for rescue seems somewhat theoretical, for lack of physicians.
Regarding the bleeding, however, we do have a bunch of active
developers:  Peter for -mom, Eric for doclifter (related to manuals),
myself for mandoc(1) (related to manuals), and maybe a few more.
So the discussion about frontend issues is not wholly theoretical,
and it's only natural the discussion turns that way, because that
part of the discussion is likely to actually have some tangible
effects in the near future.

> The logical flow isn't groff => XSL-FO, it's XSL-FO => groff.

And that is exactly where i respectfully disagree with Eric.  It
is about neither, XML and XSLT and related technologies do not come
into the picture *at all*.  I consider XML and XSLT and friends to
be among the more unpleasant examples of overengineering haunting
today's software industry.  The source code of such systems is
basically unreadable by human beings, extremely hostile to any kind
of version control and diffing, those languages make it incredibly
hard to express simple programming features in simple ways, you
regularly need stacks of at least four languages (XML, XSLT, XPath,
FO) even for simple tasks, and i could no doubt go on ranting...

One of the strengths of roff is that the basic roff macro syntax,
developed more than 50 years ago, is still the best tool for semantic
annotation i'm aware of, *obsoleting* any use of XML and XSLT and
what not.  Applied to the task of authoring of manuals, well
exploiting the strengths of roff syntax allows us to help people
write and maintain manuals in very easy formats, that it is very
easy to write toolsets for, without having to bother with XML at
all.  That is why i am here.

So the graph is

  (*) human author
       \-> roff macro syntax 
            \-> GNU troff
                 \-> type-rendered and -set output
                      \-> human reader
            \-> macro interpreter (e.g. mandoc -Tascii)
                 \-> terminal output
                      \-> human reader
            \-> macro interpreter (e.g. mandoc -Thtml)
                 \-> CSS-capable HTML
                      \-> browser -> human reader
            \-> database generator (e.g. mandocdb)
                 \-> semantic search database
                      \-> apropos(1) etc -> human reader

Note that groff appears near the beginning - providing a user-friendly
input interface, avoiding XML - *and* at the end of the chain -
providing high-quality typeset output, while auxiliary interpreters
like mandoc appear only in the middle, as a supplement to the
bigger-picture groff tool chain.

> In the simplest of terms, groff is a typesetting backend.

And it is also a way to design markup languages.  That is very easy
to overlook, given how simple the design principles of these languages
are, but i consider this fact, and the simplicity of the way roff
approaches it, to be among the crucial assets of the fifty years
of roff legacy.

> The manpages debate is largely about groff usage, not
> groff development.

There is truth in that staement, i think.  

> ancillary to backend improvement, there's a pressing need
> for groff advocacy.

Sure, that may also help to attract not just users, but developers,
too.  However, I don't think that advocacy needs to be limited to
advertising groff for writing novels (and mathematical treatises,
of course).  I do not consider it detrimental to advertise the basic
roff macro syntax for manuals, as well.  Having more than one leg
for groff to stand on - rendering system and semantic markup system
- can only make it more stable, in particular since both aspects
have been central to roff for at least 25 years now, if not more.

At least, i'm still actively advocating roff syntax for manual
authoring:

  http://www.bsdcan.org/2014/schedule/events/459.en.html

I don't think chasing away folks from roff syntax towards XML
is going to help groff, or anyone else.

> 5.  Implement new requests freely (as, for example, when Werner
>     added .fzoom) provided they do not break backward compatibility.

I agree with the principles you outline, but would like to add one
clarification to item 5: "freely" shouldn't be interpreted as "on
a whim"; adding a new request should only be considered when it
adds considerable value, and it should be done sparingly, lest the
roff request language drown in featuritis.

Yours,
  Ingo