    CRM114 Known Bugs:

1) (fixed) Parser bug... if you use a match pattern that contains an [ ] 
pattern, you MUST specify the searched string (which is usually :_dw: 
for the main data window).   The fix will be done when I make a better
(context-sensitive) parser, or switch the whole thing over to XML.

		    FIXED!!!  (better parser)

2) Matcher bug... This bug is in the GNU library, not my code.  If you
match on a window longer than 20479 characters, AND you have multiline
matching enabled, AND the pattern is of the form ".*literalvale", then
the match will FAIL even if it should have succeeded.  The TRE library
does not have this bug.  (see "make experimental")

3) Matcher bug - this is another bug in the GNU regex library.  If you
have a pattern of the form ^Q$ where Q is a single character, and you
don't specify <nomultiline>, then the match will mysteriously fail even
if it should have succeeded.  The TRE regex library does not have this
problem (see "make experimental").

3+) More on bug 3 - it seems that _many_ patterns of the form ^blah$
do not work correctly, including the simple case for a null string of
^$ even if you _do_ specify nomultiline.  The TRE regex library does
not have this problem either.

3++)  The GNU regex engine considers /./ to match not only the 
string "a", but also the empty string "".  This is in contrast
to /../ which does match "aa" but not "a".

4) Thinking bug...  If you ALTER one variable that contains another 
variable, the second variable moves as though you inserted/deleted
charactes at the START of the first variable, and then overtyped
all of the evenly matched characters.  This can lead to 
counterintuitive results; the fix is to ISOLATE any variable that
has to hold value across an ALTER operation.

    Let me know if you find any others!

	-Bill Y.
