Vin Shelton <acs(a)xemacs.org&gt; writes: > Adrian Aichner <adrian(a)xemacs.org&gt; writes: > >> COMMIT APPROVE 21.5 RECOMMEND 21.4 >> >> Thanks Vin, for the gentle nudge. >> >> Adrian >> >> xemacs-21.5-clean ChangeLog patch: >> Diff command: cvs -q diff -U 0 >> Files affected: tests/ChangeLog > > Thanks, Adrian. > > When I run it under 21.4 (with your patch applied), I get this > assertion failure: > > FAIL: Assertion failed: (null (zmacs-region-buffer)) > > I get that for both the compiled and non-compiled lisp. > > Do you know why the behavior would differ between 21.4 and 21.5? Hi Vin, I can reproduce the test failure with latest release-21-4 built from CVS. An additional (Assert (not (buffer-live-p second-buffer))) before the final (Assert (null (zmacs-region-buffer))) confirms that second-buffer is actually killed. Adding (Print-Failure "(zmacs-region-buffer) -> %S" (zmacs-region-buffer)) just for debug reveals that the outer temp buffer is returned at this point: FAIL: (zmacs-region-buffer) -> #<buffer " *temp*"> This test does not fail in 21.5, even though the (defun zmacs-region-buffer () implementation is identical. Use of (mark-marker t) in (defun zmacs-region-buffer () "Return the buffer containing the zmacs region, or nil." ;; #### this is horrible and kludgy! This stuff needs to be rethought. (and zmacs-regions zmacs-region-active-p (or (marker-buffer (mark-marker t)) (and (extent-live-p zmacs-region-extent) (buffer-live-p (extent-object zmacs-region-extent)) (extent-object zmacs-region-extent))))) seems wrong because argument FORCE always returns a marker, even though we set zmacs-regions and that region is not active. Don't know why it does not fail in 21.5.

Best regards, Adrian > > Thanks, > Vin >