GC> I understand you're concern about seeing unreadable messages, GC> 
however, I think this may be of more than theoretical interest.  It GC> is 
not only WP51D macros that can be transported in this manner.  I GC> could be 
wrong but I suspect macros from other WP versions may GC> suffer from the 
same type of portability problems.  Please correct GC> me if this is a 
misperception.  Can WP6.x macros be transported as GC> ASCII text files?
On the whole, WP6.x macros convert just fine to ASCII text files. WP5.x/DOS 
macros simply have no original text representation; the body of the macro 
file consists of two byte codes.  Many of these two byte codes correspond to 
macro codes; other correspond to such things as characters, extended 
characters, tabs and hard returns
used for formatting, etc.  What you see in the macro editor is a
translation of those two byte codes created using the WP.MRS file to 
interpret the codes (which, incidentally, is exactly how my
MacAscii program works).  You cannot simply take that visible text and read 
it into WordPerfect; you need instead something that
parses the text file and looks up the tokens in a table that
supplies the two byte codes.  WordPerfect does not supply such a
capability (but a number of the rest of us did provide one -- mine, again, is 
MacAscii).
Starting with WP5.1/Win, WordPerfect abandoned this approach and
started using a macro file that is in essence an ordinary WordPerfect text 
file.  In the document body, the user provides source code,
which is (except as described below) visible as ordinary
WordPerfect text.  The program compiles this into the form the
machine executes, and stores the compiled version in the prefix
(header) of the macro file.  The user, having only the text, can
easily recreate the macro by compiling (thus people distributing
macros in cyberspace really ought to strip out the compiled code
to save bandwidth -- they don't generally do it, even though one
of my programs will do the stripping for them).  The program, on the other 
hand, has no need for the source code once it has been compiled
(and so lots of us have written programs to strip out the source
code, resulting in smaller macro files -- it also allows macro
writers to distribute their macros while not distributing their
source code).
The exception referred to above is this: in certain contexts, a WP macro 
needs something stored as a code, not as text.  Suppose you want to do a 
search for a tab code.  Specify the search string this way: "[TAB]".  Whoops. 
 WordPerfect thinks you want to search for a string consisting of a left 
bracket, an upper case T, and upper
case A, and so forth.  So what you actually store is a code
(called, at least in 5.x/Win) a "macrofunc."  When displayed in
WordPerfect, the macrofunc for a tab as a search string will look like this: 
"[TAB]".  Visually, that is the same as the string
discussed above.  But in a WordPerfect file, it is entirely
different.  What do you do when you convert to ascii?  WordPerfect simply 
drops the macrofuncs.  (People posting macros either do or do not type in the 
visible reprepresentation, causing confusion
either way.)  A program I wrote (but never released) gives you the ascii 
representation automatically, for 6.x macros.  If you simply read such a text 
into WordPerfect, the program will treat the
visible representation as a string, not as a macro func.  My
unreleased program tries to interpret such strings as macrofuncs, comparing 
the result to the list of macrofuncs it maintains, and
reverting to text if there is no match.
Your other problems in converting 6.x macros to ascii text are the usual ones 
of how an ascii text is to handle WordPerfect characters not in the range 
32-127 ascii, how to distinguish hard from soft
returns, how to distinguish hyphens from minus signs, etc.  Little of this 
causes a real problem, particularly if you use a conversion program that 
handles the characters not in the 32-127 range
reasonably.
Bottom line:  6.x macros can be transported as ascii text, with
some minor annoyances and problems along the way, which it would be helpful 
to mark with comments in the macro text.
--- SLMAIL v4.0a  (#0304)
---------------