=================================================
PRegEx Version 2.0 Issues List
=================================================

=============== CURRENT ISSUES ============

Note: Latest bug list updates will generally be found here:

  http://openxtras.org/pregex/

Not yet fixed:

  None.

Still on the wish list (not likely to be fixed):

  - Add an optimization for when the search/replace string is the
    same from one call to the next (which is commonly the
    case). (Either have the engine notice automatically, OR allow a
    special token to be passed for SearchStrL which means to use the
    previous SearchStrL.)

Not going to be fixed in 2.0:

  - Can't write files to top level of hard drive (at least on Mac)
      (Adobe/MOA issue -- can't do anything about it.)

  - Currently, "-" and "\" are considered special in _Translate()
    EVEN when they are specified via the escape sequences \-, \\,
    \x2D, or \x5C.  In these cases, they should be treated as
    literal characters in the translation tables.  (Thanks to Arno
    Oesterheld.)  Two workarounds are available to this:
    
    ==> Workaround 1: to map a dash, make it the first character in 
    the input mapping. To map a slash, make it the last character 
    in the input mapping. For example:
        re_tr(foo, "-a-z", "!z-a") -- dashes to bangs; invert alphabet
        re_tr(foo, "a-z\", "z-a!") -- backslash to bang; invert alphabet

    ==> Workaround 2: use "-" as a range operator to include dash 
    and slash in a range with the surrounding characters. For example:
        re_tr(foo, ",-.", ",!.") -- convert dashes (only) to bangs
        re_tr(foo, "[-]", "[!]") -- convert backslashes (only) to bangs

        
=============== KNOWN GENERAL ISSUES ============

- Efficiency with large buffers: Operating memory usage

  MOA unfortunately allows no way to directly access and modify the
  contents of a string buffer contained in a list, without making
  several in-memory copies of the data along the way.  To manipulate a
  very large buffer, then, we recommend that you have at least 4x the
  length of the buffer available as free memory, before you start
  (check the freeBytes).  If you are doing a search-and-replace that
  involves lots of data, you may need up to 5x.


- Efficiency with large buffers: Persistent storage

  PRegEx keeps a copy of the most recently-matched buffer in memory
  (because all high-level functions call PRegEx_SetSearchString
  internally).  It also keeps a second buffer of the entire last
  matched portion of the string, which could be as large again as the
  string itself.  This is needed to support getting backreferences.
  If you are using large buffers and want to free up some memory
  before your next match, call PRegEx_Clear to release all these
  buffers.


- Trailing unmatched backreferences

  A bug in PCRE causes the number of available back references to be
  underreported when the last of a set of backrefs did not match.  For
  example, both of these should set 3 back refs, but in the second
  case, the (Chris) capturing subexpression did not match, so PCRE
  acts as if there had only been two back refs.  This behavior is
  understandable, but it is inconsistent with Perl's behavior.

  PRegEx_Search(["Chris"], "((Ravi)|(Chris))") -- sets 3 back refs
  PRegEx_Search(["Ravi"] , "((Ravi)|(Chris))") -- sets 2 back refs

  Philip Hazel, the creator of PCRE, has been notified of this issue.


=============== KNOWN LIMITATIONS ============

- Symbol to string conversion

  Anywhere PRegEx converts symbols to strings, the maximum length of
  the resulting string is 255 characters.


- String to symbol conversion

  Anywhere PRegEx converts strings to symbols, it is simply making the
  corresponding MOA call, which may allow the creation of symbols with
  characters that are not technically within the legal set of allowed
  characters for symbol names.


