Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwvax!tank!ncar!ico!vail!rcd From: rcd@ico.ISC.COM (Dick Dunn) Newsgroups: comp.text Subject: Re: Troff Macro Programming A: Part 1 [repost] Summary: What is troff, anyway? Message-ID: <15795@vail.ICO.ISC.COM> Date: 25 May 89 00:57:05 GMT References: <18@nx32s.anduk.co.uk> <15768@vail.ICO.ISC.COM> <20@nx32s.anduk.co.uk> Distribution: comp Organization: Interactive Systems Corp, Boulder, CO Lines: 144 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, > [[ : It's Mr. Quin, or `Lee' -- simply using a surname is generally > considered rude in England. ]] 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.