Adrian Aichner wrote:
replace-in-string implements an arbitrary limit bug that would turn
some
guys in Redwood green with envy :-)
The second r-i-s does NOT honor case-fold-search in (emacs-version) "XEmacs
21.4 (patch 9) \"Informed Management (RC1)\" [Lucid] (i586-pc-win32) of Sat
May 25 2002 on D5DC120J" "XEmacs 21.5 (beta7) \"broccoflower\"
[Lucid]
(i586-pc-win32, Mule) of Sat Jul 06 2002 on D5DC120J"
It does, however work correctly in "XEmacs 21.1 (patch 14)
\"Cuyahoga
Valley\" [Lucid] (i386-pc-win32) of Mon May 21 2001 on D5DC120J"
Who has the inside story?
I think it's related to this ChangeLog entry:
* subr.el (replace-in-string):
Rewrite this function to avoid N^2 behavior with large strings --
catastrophic with the new Windows selection code! (Apparently the
author of this function didn't realize there was a fun
replace-match that could make his life much easier, because we
duplicated the entire logic. The new version is smaller, easier
to understand, much more robust, and has extended features --
those of replace-match.)
Given the size of the entry, and the tone it's written in, one does not find
it difficult to figure out the author ..... :-)
2000-07-30 Ben Wing <ben(a)xemacs.org>
The problem we have is that re-search-forward does not currently honor
case-fold-search.
--
Didier Verna, didier(a)lrde.epita.fr,
http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47
94276 Le Kremlin-BicĂȘtre, France Fax.+33 (1) 53 14 59 22 didier(a)xemacs.org