🚀 go-pugleaf

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 \<name> 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