Re: [WICKED BREAKAGE] replace-in-string (was: patcher.el<1.12, 1.13> have broken patcher-logmsg-commit)

drv> Adrian Aichner wrote: drv> I think it's related to this ChangeLog entry: drv> * subr.el (replace-in-string): drv> Rewrite this function to avoid N^2 behavior with large strings -- drv> catastrophic with the new Windows selection code! (Apparently the drv> author of this function didn't realize there was a fun drv> replace-match that could make his life much easier, because we drv> duplicated the entire logic. The new version is smaller, easier drv> to understand, much more robust, and has extended features -- drv> those of replace-match.) Seems like the re-writer did not realize a few things either :-) drv> Given the size of the entry, and the tone it's written in, drv> one does not find it difficult to figure out the author drv> ..... :-) drv> 2000-07-30 Ben Wing <ben(a)xemacs.org&gt; drv> The problem we have is that re-search-forward does not drv> currently honor case-fold-search. It does! However, the use of (with-temp-buffer ...) for strings > 50 chars (42 I would understand, but 50, yuck!) in replace-in-string makes is use the default-value of case-fold-search! Didier, both of us seem to be fans of case-fold-search t, yes? But hey, patcher will work for people who have it set to nil :-) -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/