Re: 'make check' and the next release.

SY> I think Jerry James just about has these lisp test failures SY> under control. Right Jerry? Do you need a hand? Yes, he does---it's a policy issue. This needs discussion before patching. The Lisp test fails because GNU in its apparently bottomless sink of wisdom has decreed that (split-string " data " " +") => ("data") which makes sense in that case, but their implementation gives (split-string " data " " ") => ("" "data" "") which is weird, and (split-string ",,data,," ",") => ("" "data" "") which is catastrophic (think "Gnumeric", "Save As", "CSV"). So we have a choice between sanity (revert split-string to the old behavior) and GNU compatibility (which requires changing the tests and IMHO adding a function `split-string-sanely' with the old behavior). SY> The regexp test failures, anyone working on those? I have a fix for the regexp test failures, which will be submitted shortly. However, this is (apparently) going to be controversial because there is currently a regression test (with-temp-buffer (insert "This is a test buffer.") (goto-char (point-min)) (search-forward "this is a test ") ; search succeeds (looking-at "Unmatchable text") ; force a match failure (replace-match "") ; replace PRIOR match! (Assert (looking-at "^buffer.$"))) I think this is incredibly evil behavior; there is no way to know how long ago or where the successful match may have been. Ie, the current behavior implies random data corruption in (with-temp-buffer (insert "This is a test buffer.") (goto-char (point-min)) (search-forward "this is not a test ") ; search fails (looking-at "Unmatchable text") ; force a match failure (replace-match "") ; replace who knows what! (Assert (looking-at "^buffer.$"))) So my patch fixes the current test failures, which implies changing the behavior of `replace-match', and changes the test above to expect an error when `replace-match' is called. -- 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.