Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!tut.cis.ohio-state.edu!unmvax!gatech!emory!dtscp1!scott From: scott@dtscp1.UUCP (Scott Barman) Newsgroups: comp.text Subject: Re: What features would you like in GNU troff? Message-ID: <763@dtscp1.UUCP> Date: 10 Jun 89 06:41:47 GMT References: <622@rna.UUCP> <22@nx32s.anduk.co.uk> Reply-To: scott@dtscp1.UUCP (Scott Barman) Distribution: comp Organization: Digital Transmission Systems (a subsidiary of DCA), Duluth, GA Lines: 38 In article <22@nx32s.anduk.co.uk> lee@nx32s.UUCP (0000-Liam R. Quin) writes: >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]]. The problem with this is with the older versions of troff it will interpret the string named "[" then append "array" to it and the number register of "[" then "index]]" appended. Once you do this, you have to sit and re-edit many megabytes of documentation already in existance. This is not fair to those of us who has been doing this for a few years! Didn't Berkeley do something like this for long names? I think they took great pains in keeping the compatibility! Their method was to use the space as the delimeter. For example, to use the number register named "saved", one would do: Part of a sentence then \n( saved and the rest... ^^ Note 2 spaces The extra space is needed for the delimeter. As I recall from their docs, they said that the extra space is required and is the cost for using this feature. I do not see anything wrong with this since the space is not a legal for use in nameing registers, etc. AND IT DOES NOT BREAK ALL THE OLD DOCUMENTS! PLEASE STOP TRYING TO BREAK OUR *MEGABYTES* OF DOCUMENTATION!!! I mean manuals, functional and design documents are painful enough. We do not want to have to re-edit them if it can be avoided! *AND* we (read: me, the part-time sys admin., full time programmer) do not want to maintain N versions of troff! I did it once and it was not fun or easy! -- scott barman {gatech, emory}!dtscp1!scott