[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] troff syntax and useability

From: Ralph Corderoy
Subject: Re: [Groff] troff syntax and useability
Date: Thu, 29 Aug 2002 11:08:36 +0100

Hi Ted,

>   The great strength of troff is the flexibility of the basic language
>   and its programmability --- it can be made to do almost any
>   formatting task.

That's where 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
> tj/j/his ...

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.


reply via email to

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