Re: [Groff] [groff] mission statement 3

[Doug McIlroy]

I have just seen that these comments, which have been gestating
for some time, are somewhat outdated by the appearance of mission
statement 3. Still I think they may be of some use.

Mission statement 2 begins with a precis of what groff is, but no     |
overt expression of the purpose of the groff project, as I would      |
expect of a mission statement. I think this lack should be rectified. |

The rest of the document is a to-do list, expressed in terms of       |
"frontend" and "backend", which apparently mean macro package,        |
and groff proper. Things even further front (eqn, etc) or back        |
(grops, etc) are not mentioned, though surely they are in the         |
project's purview.

I'm skeptical of Knuthian line-breaking, which heads the to-do
list. I have been frustrated too often by trying to outwit AI in Word
I have just seen that these comments, which have been gestating
for some time, are somewhat outdated by the appearance of mission
statement 3. Still I think they may be of some use.

Mission statement 2 begins with a precis of what groff is, but no     |
overt expression of the purpose of the groff project, as I would      |
expect of a mission statement. I think this lack should be rectified. |

The rest of the document is a to-do list, expressed in terms of       |
"frontend" and "backend", which apparently mean macro package,        |
and groff proper. Things even further front (eqn, etc) or back        |
(grops, etc) are not mentioned, though surely they are in the         |
project's purview.

I'm skeptical of Knuthian line-breaking, which heads the to-do
list. I have been frustrated too often by trying to outwit AI in Word
and fmt. Pseudo-Knuthian line-breaking in the latter is a bloody
pain. This email was formatted with fmt. A glance at the previous
paragraphs, where the line length is marked, shows the capricious
result. Some paragraphs below are even more astonishing.

As for real Knuthian line-breaking: when forced to use TeX, I
typically resort to "/sloppy" mode to avoid the temper tantrums
TeX throws when it can't do a good job.

But my fundamental complaint about Knuthian line-breaking is
that anything that takes 66 journal pages to describe can't be
right. It is out of keeping with the Unix ethos of simplicity and
generality--and with the "small size" of groff that the mission
statement praises.

There is one property of TeX (and HTML) that's worth emulating:
recursive nesting. It's a challenge to the preprocessor model
(eqn, tbl, pic), but one that deserves serious consideration.
How about letting "preprocessors" be called by piping segments out
and back, not only by piping in? (This is a standard facility of
the sam editor. The line breaks in this email were set by piping
out to fmt.)

Another issue worthy of hard thought is the handling of
cross-references, and the creation of parallel interconnected
galleys, e.g. table of contents and bibliography, to be
collected--perhaps after certain massaging--into a single document.
These things are handled by a collection of special purpose tricks
in both TeX and groff. Is there a general pattern that can be
supported here?

I have to agree that making it easy to incorporate new typefaces
from disparate sources is an important task, nasty as it may be.

As for frontends, I would like to see some modularization of macro
packages. The fact that mom is as big as classic troff itself should
give one pause. To what degree is it possible to separate various
style-sheet issues into orthogonal subsets that can be reused? Some
potential modules might be: text style (paragraphing, fonts, etc)
document descriptors (title, author, etc), page matters (head,
foot, columns), section structure (may invoke different body-text
styles) etc. Is any enabling architectural change in groff proper
needed to support this? (Notice that the topic is not unrelated to
recursive nesting.)

I agree that good candidates for updating the man macros are likely
to be found among the readership of this mailing list. However,
the biggest problem with man pages is that people don't write them.
groff_mom(7) is a recent example--all it does is point somewhere
else. The biggest culprit is info--a maddeningly archaic facility
to which Gnu clings tenaciously. Unless it can be foreseen how new
man macros would displace texinfo from its throne, the exercise
will largely be in vain.

[Full disclosure. Having edited the 7th to 10th research-edition
manuals, I am very partial to man pages, though I have no special
affinity for the man macros.]

While a to-do list is on the table, is there anything that needs
to be done for eqn, tbl, pic, and other preprocessors?

I think eqn's syntax largely improves on its successors', to borrow a
phrase from Tony Hoare. I only see a few minor annoyances. One would
like to be able to describe matrices by rows as well as by columns,
and a snappier notation for subscripts and superscripts a la TeX
would be convenient.

Incidentally, I do not think TeX's math spacing by operator
precedence is much preferable to eqn; it's hard (or impossible)
to undo when it's inappropriate.

Tbl is a bigger deal, because nesting comes to the fore. I sweated
a while back to make a table that contained pic diagrams, images,
and equations, as well as plain text. The grail remains to be found.

In pic, the thing I miss most is polygons (preferably allowing arcs
and splines as edges) that can be filled.  After that, the next step
is a big one: lightweight constraint-based drawing; Van Wyk's Ideal
(SIGPLAN Notices 16:6) is a proof of concept. Can that be gracefully
folded into the current pic model?

Of all the preprocessors, Refer is probably the weakest. One of
the "parallel galleys" mentioned above, it may profit from some
architectural support. It certainly needs style sheets--another
aspect of frontend modularity. I would suggest, too, that the set of
categories (author, date, etc) be modest, but extensible. Bibtex's
"exhaustive" list is overkill, I think.

Speaking of macros, is there any hope of reconciling the macro
schemes of groff, pic, and eqn?  Or is it obviously silly to try?

Finally, I repeat that the mission statement should offer a guiding
purpose as well as a to-do list.

Doug