--- code/trunk/ChangeLog	2007/08/21 11:46:08	226
+++ code/trunk/ChangeLog	2007/08/21 15:00:15	227
@@ -145,23 +145,25 @@
 
 25. Using pcregrep in multiline, inverted mode (-Mv) caused it to loop.
 
-26. Patterns such as [\P{Yi}A] which include \p or \P and just one other 
+26. Patterns such as [\P{Yi}A] which include \p or \P and just one other
     character were causing crashes (broken optimization).
-    
+
 27. Patterns such as (\P{Yi}*\277)* (group with possible zero repeat containing
-    \p or \P) caused a compile-time loop. 
-    
+    \p or \P) caused a compile-time loop.
+
 28. More problems have arisen in unanchored patterns when CRLF is a valid line
     break. For example, the unstudied pattern [\r\n]A does not match the string
     "\r\nA" because change 7.0/46 below moves the current point on by two
     characters after failing to match at the start. However, the pattern \nA
-    *does* match, because it doesn't start till \n, and if [\r\n]A is studied, 
-    the same is true. There doesn't seem any very clean way out of this, but 
-    what I have chosen to do makes the common cases work: PCRE now takes note 
-    of whether there can be an explicit match for \r or \n anywhere in the 
-    pattern, and if so, 7.0/46 no longer applies. As part of this change, 
-    there's a new PCRE_INFO_HASCRORLF option for finding out whether a compiled 
-    pattern has explicit CR or LF references. 
+    *does* match, because it doesn't start till \n, and if [\r\n]A is studied,
+    the same is true. There doesn't seem any very clean way out of this, but
+    what I have chosen to do makes the common cases work: PCRE now takes note
+    of whether there can be an explicit match for \r or \n anywhere in the
+    pattern, and if so, 7.0/46 no longer applies. As part of this change,
+    there's a new PCRE_INFO_HASCRORLF option for finding out whether a compiled
+    pattern has explicit CR or LF references.
+
+29. Added (*CR) etc for changing newline setting at start of pattern.
 
 
 Version 7.2 19-Jun-07