VETO Moving discussion to xemacs-beta. Reply-To & MFT set. Aidan> lisp/ChangeLog addition: Aidan> 2005-02-20 Aidan Kehoe <kehoea(a)parhasard.net&gt; Aidan> * subr.el (replace-in-string): Throw an Aidan> invalid-argument error if the pattern matches the empty Aidan> string, preventing an infinite loop in that case. The semantics of a regexp that matches only the empty string at point are well-defined: the replacement string should be inserted once. OTOH, if it matches a non-empty string, it should replace that string _once_ (and due to the default greedy semantics, will prefer it to the null match). Note that replace-regexp-in-string (recently? synched to GNU 21.2) just advances by one after doing the replacement for a null match. I didn't understand this when it was suggested (in either this context or a similar one) a couple months ago. I still think this is incorrect: note that (replace-regexp-in-string "a*" "b" "ac") => "bbc" and I'm pretty sure that with a similar adjustment (replace-in-string "ac" "a*" "b") => "bbc" (or maybe "bbcb") but (IMO) the correct result for both is "bcb". The reason for the actual result is that after finding and replacing the match "a", we'll be looking at "c", and match and replace the null string, and only then move past the ?c. But I would argue the algorithm should match the null string at point iff it has moved since the last replacement. So it matches "a" (because it's greedy) and replaces it. Now looking at "c" it matches the null string, but it hasn't moved so it should ignore that match. Skipping past ?c, it now is looking at "", which it does match, and should be replaced by "b", giving "bcb". We should review the C code for this bug (the lack of trailing "b" is arguably convenient, but the replacement of a single "a" with "bb" is definitely a bug, right?) We should review buffer code for this bug. We should check current GNU and notify them if they're busted. 21.4 will need these patches, I'm pretty sure. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Aidan> Well-defined by Perl and other regexp engines, you mean? No, well-defined in abstract algebra and language theory. The rest of that crap is mere implementation. Aidan> Its Perl equivalent does do what you say, though (ignoring Aidan> that your example result didn’t pay attention to the Aidan> starting anchor empty match); There is no empty match at the starting anchor, there is a nonnull match there. IMO, Perl is broken. So is PHP. Maybe we'd better check POSIX, I could very likely be wrong: the Perl guys are unlikely to screw up on regexps! On second thought, Python gives the answer I prefer: 'bcb' and furthermore defines the operation in language theory terms, not via a reference implementation: `sub(pattern, repl, string[, count])' Return the string obtained by replacing the leftmost non-overlapping occurrences of PATTERN in STRING by the replacement REPL. If the pattern isn't found, STRING is returned unchanged. ("Leftmost non-overlapping" actually means "if matches overlap, the leftmost is replaced, and any matches that overlapped it are ignored", according to the Python implementation: 'bba' That's what I want it to mean. ;-) Aidan> [They are.] Aidan> Whee. Thanks for checking! Now comes the fun. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.