Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!ukc!warwick!anduk!lee From: lee@anduk.co.uk (Liam R. Quin) Newsgroups: comp.text Subject: Re: What features would you like in GNU troff? Summary: braces or brackets for long names? Message-ID: <22@nx32s.anduk.co.uk> Date: 8 Jun 89 22:04:34 GMT References: <622@rna.UUCP> Reply-To: lee@nx32s.UUCP (0000-Liam R. Quin) Distribution: comp Organization: Unixsys (UK) Ltd, Warrington, England Lines: 48 In article <622@rna.UUCP> dan@rna.UUCP (Dan Ts'o) writes: >In article jjc@jclark (James Clark) writes: > I implemented a NROFF-like program for "typesetting" BRAILLE (also >does ASCII, source compatible with NROFF/TROFF). For long names, I used >\{nameofanylength}. Of course macros can be of any length, and builtin >commands also had more friendly aliases, like .space and .break and .page >can be used for .sp, .br and .bp. The only trouble with this is that you can't have long special symbols like \{pound-sterling} or \{dagger}, because \{ already means the "then" of an if-then-else, and is legal in generally the same places. Either \[name] or \ are better. I prefer \[...], because then I can use existing bracket-matching software (e.g. the % key in vi) to check things like \\*[array.\\n[index]]. Also, it is useful if all the escape sequences that recognise delimiters understand [...] (or whatever) as well. Currently, ditroff does not check that the two delimiters are the same in all cases, so \l[3i] happens to work, at any rate in the version I have here, but this is too easy to do by mistake. \h[\w[\\*[array.\\n[index]]u]u] is not much better then \h'\w'\\*'array.\\n'index]'u'u' and less robust than otroff's \h'\w\:\*(A\\n(Ix\:u'u' (\: was an undocumented delimiter) but at least yuo can check it automatically, anda combination *is* more readable: \h[\w'\\*[array.\\n[index]]u'u] looks best to me. > There were some commands missing from TROFF that were need for >BRAILLE production, like some way of putting a header string at the end >of the first line of every page: You migt be able to do this with a macro: * put the string in place at the top right * reduce the line length so the text doesn't overwrite it * make a trap for one line down * In the trap, * increase the line length * remove the trap But it isn't easy to get right first time... 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