groff
[Top][All Lists]
Advanced

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

Fwd: [Groff] troff syntax and useability


From: Rob Scovell
Subject: Fwd: [Groff] troff syntax and useability
Date: Thu, 29 Aug 2002 22:21:26 +1200

I am more convinced than ever that groff is some ancient Greek mystery religion.

This email reminds me vividly of Greek exegesis (textual analysis and interpretation) classes from my theology student days. And one of the more difficult texts at that...

As for 'lacking an accurate conceptual model' -- is that not the problem that every religion down the ages has tried to address?

The Zen approach is looking increasingly realistic!

Begin forwarded message:

From: Ralph Corderoy <address@hidden>
Date: Thu Aug 29, 2002  10:08:36  PM Pacific/Auckland
To: address@hidden
Cc: groff list <address@hidden>
Subject: Re: [Groff] troff syntax and useability


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 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
days.)

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.


Ralph.

_______________________________________________
Groff maillist  -  address@hidden
http://ffii.org/mailman/listinfo/groff



reply via email to

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