From: Ralph Corderoy <address@hidden>
Date: Thu Aug 29, 2002 10:08:36 PM Pacific/Auckland
Cc: groff list <address@hidden>
Subject: Re: [Groff] troff syntax and useability
The great strength of troff is the flexibility of the basic language
and its programmability --- it can be made to do almost any
That's where troff.org stops quoting. Well, you don't want to clutter
the front page up too much, do you ;-)
But the flexibility comes at a high price --- troff is often
astonishingly hard to use. It is fair to say that almost all of the
UNIX document preparation software is designed to cover up some
part of naked troff.
"The UNIX Programming Environment"
Brian W. Kernighan & Rob Pyke (1984)
(It's Pike, or `rob pike, esq.' as comp.os.plan9 readers see these
The terseness you refer to undoubtedly originated (like much UNIX
terseness) in a desire to avoid pressing more keys than necessary ---
especially on teletypes, where correcting typos was a nightmare since
"erase and overtype" was not an option: instead, it looked like
Could well be true. The above book talks about # and @ being the delete
and line kill characters, rather than slash, but I guess it was a local
thing depending on the hardware used. I remember # on one I used.
But troff was also written in PDP assembler and two character commands
allow easy comparision as 16-bit integers. In fact, when quizzing
Kernighan over some Bell Labs troff behaviour because I couldn't get to
the bottom of a piece of C source just some 30-odd lines long he said
"all that said, you do appear to be right about the possibility of
an uninitialized variable in getword(). the flow in that function
has defeated me, though i've struggled with it from time to time; i
finally decided that it wasn't worth worrying about. it really is a
direct transliteration of the pdp-11 assembly language version."
So when it made the transition from PDP assembler to C, it doesn't mean
it got any more understandable at the same time. I was pleased it
wasn't just me that this routine had beaten :-)
However, I think the real difficulty in using troff is not the
terseness. I think it lies in the necessity to understand the
internals, at least to some degree, so that you know what really goes
on when a request or other formatting directive is executed.
Absolutely agree here. You don't have to know exactly how it does what
it does internally, but you do need a conceptual model that is accurate.
That's what I'm lacking.
Groff maillist - address@hidden