🚀 go-pugleaf

In article <20@nx32s.anduk.co.uk>, lee@anduk.co.uk (Liam R. Quin) writes:
> In article <15768@vail.ICO.ISC.COM> I wrote:
> > In article <18@nx32s.anduk.co.uk>, lee@anduk.co.uk (Liam R. Quin) posted
> > the beginning of an introduction supposedly for troff.
> > However, much of
> > it is specific to a formatter based on troff but significantly changed.
> This is only superficially correct.
> The notes apply to all the versions of troff I've seen.

It is much more than "superficially correct"!  It doesn't matter if it ap-
plies to all versions of troff you've seen--that's a personal view.  I can
as easily say that much of it applies to *no* version of troff I've seen.

The point is that, as far as I can tell, the extensions do not exist in
*any* version of troff that AT&T has ever sold or licensed.  That's a lot
of instances of troff over the years even if it isn't all of them.

> > But in the article by Quin,
> [[ <flame-on>: It's Mr. Quin, or `Lee' -- simply using a surname is generally
>    considered rude in England.</flame-off> ]]
This flame is more rude than the supposed offence!  Clearly no offense was
intended.  In the US, whence I posted:
	- It is considered rude to address a person by given name without
	  some introduction (excepting certain salespeople and recruiters,
	  who don't understand "rude"...but that doesn't apply here.)
	- Neither "Liam" nor "Lee" is obviously a male's name.  I may not
	  have searched far enough by this point in the followup, but not
	  knowing sex, I could at best use "M- Liam", which is an affecta-
	  tion and would still leave open the possibility that, in choosing
	  a more formal address, I should have said "Dr Liam".
	- The surname alone is considered proper in this context.

> > "old troff" comments also apply to "new troff" (i.e., ditroff).
> I don't think that 1978 is very new...

The first ditroff appeared more on the order of early '80's.  After that,
pic was added, then grap was added.  These require changes in troff.  Grap
corresponds to DWB 2.0, which is probably no older than 1986 or 1987.  The
recent changes also give a much-improved nroff.

> I chose to use longer names in some of the examples for several reasons.
> * It is *much* easier to start off with a higher-level representation.

I agree, but it doesn't work!  I have often wished for longer names, and
for some safer way to partition the name space.  But one of the uses of
troff input format is as an exchange format.  If one takes great liberties
with the notation, that use is lost.  (My own teaching experience suggests
that one is better to stay on the straight and narrow; students have enough
to remember just what's correct and what isn't, let alone some sense of
conditional validity and substitution.)

>   In other words, the macros are easier to understand if you use long names.
>   If your troff doesn't support them (and there are lots that do, including
>   SoftQuad's, Proficient's, and the UCB (non-proprietary) version), it is
>   actually not that hard to add, and worth-while if you do a lot of work
>   with ditroff.

It is not possible to add long names to troff without either modifying
troff itself or adding a separate translating component.  That is, either:
	- Obtain a source license for DWB and do some programming.  (This
	  raises the possibility of getting it "wrong"--i.e., inconsistent
	  with other forms of the extension.  It's too expensive anyway.)
	- Adding a pre-processor to translate long names down to two-char-
	  acter names.  This looks simple at first, but it involves pre-
	  processing macro files and .so files as well...which in turn
	  requires understanding almost all of the input language.
I can't see either of these as practical.

Again, it may or may not be worthwhile--for me it would not be, because the
documents I prepare using troff may have to be formatted on at least five
different types of machines even before I send them to anyone else.

I am interested in the "UCB (non-proprietary) version"--the last I'd heard,
Berkeley had not managed to "free" nroff/troff from AT&T code and they
didn't have anyone working on it.  Details?

> But the examples are for teaching, so I value clarity very highly.  You
> will probably have to change them to get them to do exactly what you
> need, so I might as well write them in the way that I have.

Again it's a matter of teaching preference, but I've found that examples
which don't work letter-for-letter can be very disturbing.  I contend that
it is possible to write troff examples which *need not* be changed at least
to work for the original purpose.

> > I think it's an exceptionally bad idea to start right off teaching people a
> > notation which is peculiar to a vendor-specific extended version of troff
> > and not supported by the "reference" version.
> It is not clear to me what you mean by `reference'.

I mean the version which is sold/licensed/distributed by AT&T, which
presumably forms the base for at least some of the other extended
versions.  This "version" is actually a series of versions over the years,
but none of them have the long-name extensions.

> > To be compatible with troff, [.ps12] would have to mean the same as
> > 	.ps 12
> > i.e., set point size to 12.  It's not clear how you'd invoke the ps12
> > macro.
> As soon as you define a macro called ps12, you no longer have to be
> compatible in this respect.

Who are "you"?  Troff input almost always involves two parties--the
document author and the macro author.  They can (and frequently do) get
into conflicts.  Suppose that it's the document author who defines ps12 and
uses it with macros which have been scrunched.  (Note in passing:  The
business of pulling out the separator between command and arguments is a
Bad Idea...but it's still common.)

> Troff knows whether or not a macro/string/register has been defined.
> It simply doesn't tell the user (although some versions produce a
> warning, and it's fairly easy to change ditroff to do this).

One can make a good case either way for number registers.  However, macros
and strings share the same name space with one another--and with the
built-in commands.  It is an important, documented, time-honored property
of troff that "...control lines with unrecognized names are ignored."

> So troff can, in fact, do this.  It could probably even work out whether
> to do [ or xxx in \*[xxx] depending on whether xxx was a defined name,
> although there seems to be no need for this.

No, not if the string [ is defined.  If there has been a
	.ds [ stuff
then \*[xxx] *must* produce stuffxxx]

> I found a few bugs in macro packages like -mm to do
> with forgetting to initialise registers,...

I certainly won't question that you've found bugs in mm!  But I wonder
which were bugs and which just relied on uninitialized registers implicitly
having value 0?

> ...and there is a strong case for adding better error messages to
> troff...

Quite true.  But one ought to be careful to distinguish "errors" from
"warnings", in order not to bury useful error messages where they won't be
noticed.  For example, using an undefined command is probably a warning
that one ought to be able to switch on during debugging, but (per above)
it's not an error so you don't want to see it normally.
-- 
Dick Dunn      UUCP: {ncar,nbires}!ico!rcd           (303)449-2870
   ...CAUTION:  I get mean when my blood-capsaicin level gets low.