Clarify some details about the regsexp implementation.
authorChris Hanson <org/chris-hanson/cph>
Sat, 6 May 2017 20:55:07 +0000 (13:55 -0700)
committerChris Hanson <org/chris-hanson/cph>
Sat, 6 May 2017 20:55:07 +0000 (13:55 -0700)
doc/ref-manual/strings.texi

index d09044a88eb01cc5f41a92931f09000729ef5db6..568bf91f002341aca56fc0ba3d5f41891491d117 100644 (file)
@@ -1170,9 +1170,10 @@ s-expression syntax, which we call a @dfn{regular s-expression},
 abbreviated as @dfn{regsexp}.
 
 Previous releases of MIT/GNU Scheme provided a regular-expression
-mechanism nearly identical to that of GNU Emacs version 18.  This
-mechanism still exists but is deprecated and will be removed in a
-future release.
+implementation nearly identical to that of GNU Emacs version 18.  This
+implementation supported only 8-bit strings, which made it unsuitable
+for use with Unicode strings.  This implementation still exists but is
+deprecated and will be removed in a future release.
 
 @menu
 * Regular S-Expressions::
@@ -1535,6 +1536,11 @@ match ends, and each @var{register} is a pair @code{(@var{key}
 . @var{contents})} where @var{key} is the register's name and
 @var{contents} is the contents of that register as a string.
 
+In order to get reliable results, the string arguments to these
+procedures must be in Unicode Normalization Form C.  The string
+implementation keeps most strings in this form by default; in other
+cases the caller must convert the string using @code{string->nfc}.
+
 @deffn procedure regsexp-match-string crse string [start [end]]
 The @var{crse} argument must be a value returned by
 @code{compile-regsexp}.  The @var{string} argument must satisfy