Path: utzoo!attcan!uunet!mcvax!ukc!warwick!anduk!lee From: lee@anduk.co.uk (Liam R. Quin) Newsgroups: comp.text Subject: Re: Troff Macro Programming A: Part 1 [repost] Message-ID: <20@nx32s.anduk.co.uk> Date: 19 May 89 15:04:25 GMT References: <18@nx32s.anduk.co.uk> <15768@vail.ICO.ISC.COM> Reply-To: lee@anduk.UUCP (Liam R. Quin) Distribution: comp Organization: Unixsys (UK) Ltd, Warrington, England Lines: 102 In article <15768@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: > 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. > I assume he's talking about one by ``SoftQuad Publishing Software'' This is only superficially correct. The notes apply to all the versions of troff I've seen. Some of the examples use long names because it makes them easier to read, but I have included ``standard'' versions too. There are a few programming techniques that you can't actually do unless you have long names; I intended at least to mention these, although not to rely on them of course. I'll wait to see if anyone found the stuff useful before posting any more, of course. > But in the article by Quin, [[ : It's Mr. Quin, or `Lee' -- simply using a surname is generally considered rude in England. ]] > "old troff" comments also apply to "new troff" (i.e., ditroff). I don't think that 1978 is very new. I'm sorry if you were confused by this. Let me know if your troff doesn't run the `stack' example, though, which was intended to be fairly portable! 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. 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. Note: In some of the DWB derivatives that support long names the syntax is \C'name' instead of [name], but the changes are fairly straight-forward. * I have several versions of troff here, and the examples with ditroff and nroff as well as Osanna's `otroff' itself [ancient troff? :-) :-)]. But I use versions with long names by preference. In the 2nd part (that I posted a couple of days ago), there is the first `useful' example -- numbered lists that you can nest fairly deeply -- presented first with long names (for clarity, hopefully!) and then in troff format, with the short (``bird-dropping'') style names. 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. > 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'. If you use the word in the sense that the `reference' Unix is that which runs on Mr. Ritchie's machine, then the `reference' troff is probably the Research ditroff. This isn't available to most people, however. [0.5 :-)] Seriously, though, the examples work with other troffs. It's sort of like writing F*RTRAN or BaSick [:-(] -- start off coding in a higher- level psuedo-code and then translate. And people who have a version of troff with long names get to benefit, too. > 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. If the macro is not defined, at least one such version of troff that I use takes it to mean .ps 12, optionally printing a warning. > Moreover, it's not possible to decide what to interpolate based on the > existence of a definition of register (or string) [, because the value of > an undefined number register is 0. 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). 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. I found a few bugs in macro packages like -mm to do with forgetting to initialise registers, or using the wrong name by mistake, simply by adding an optional warning to ditroff! There are some subtler bugs I found that way to do with the mis-use of tabs, too, and there is a strong case for adding better error messages to troff. I once posted some patches that do this. Lee -- Lee Russell Quin, Unixsys UK Ltd, The Genesis Centre, Birchwood, Warrington, ENGLAND, WA3 7BH; Tel. +44 925 828181, Fax +44 925 827834 lee%anduk.uucp@ai.toronto.edu; {utzoo,uunet}!utai!anduk!lee UK: uu.warwick.ac.uk!anduk.co.uk!lee