From xemacs-m  Sun Jan  5 16:32:12 1997
Received: from plg.uwaterloo.ca (dmason@plg.uwaterloo.ca [129.97.140.10])
          by xemacs.cs.uiuc.edu (8.8.4/8.8.4) with ESMTP
	  id QAA12785 for <xemacs-beta@xemacs.org>; Sun, 5 Jan 1997 16:32:11 -0600 (CST)
Received: (from dmason@localhost) by plg.uwaterloo.ca (8.7.6/8.7.3) id RAA03170; Sun, 5 Jan 1997 17:32:12 -0500 (EST)
Date: Sun, 5 Jan 1997 17:32:12 -0500 (EST)
From: Dave Mason <dmason@plg.uwaterloo.ca>
Message-Id: <199701052232.RAA03170@plg.uwaterloo.ca>
To: XEmacs beta <xemacs-beta@xemacs.org>
Subject: Re: Lazy lock broken in b34
In-Reply-To: <yviarajzu67q.fsf@atreides.mindspring.com>
References: <199701050718.CAA08228@spacely.icd.teradyne.com>
	<199701051729.KAA02964@branagh.lanl.gov>
	<m2loa7vlau.fsf@altair.xemacs.org>
	<yviarajzu67q.fsf@atreides.mindspring.com>
X-Face: %Q_F^9R-:'3MM7eZ6@E.x@f\*bgatzGv-8d%I~L[p^.F)3QF{kq\UTsu|e#?)3FPwJNvPPB
 !s*He|-*M^p*~bh"Nywm5NLL\\Rl3r(hWHY*F:$/RdKV*bS";n&#\Ov@*=]mu\}6tP<lkW*7FT|:Dm
 9ejO^{)GHJdPQaa"C\<Ak`K27?328'V(u*|jAEZR9-z!o\^j:Cb&*tx_9\KbXD*2

Sudish Joseph writes:
> 
> Lazy-lock defines it's own versions of text-property-{any,not-all} for
> XEmacs 19.11 and earlier.  These are superfluous and incorrect in
> 20.x.  This was really looking weird until I bumbled into the results
> of (symbol-file 'text-property-any). :-)

Maybe it should be released as version 20.14 so that all the
aftermarket packages don't die?  1/2 :-)

> BTW, it'd be nice if symbol-file was interactive.  It's very useful
> while debugging.

I suppose this doesn't exist in 19.15.  I was just thinking today how
useful such a primitive would be when trying to figure out how to do
weird stuff in elisp (going and looking at .el files is good, but
finding the right one is sometimes a bit of a pain).

Re: to release 19.5/6 or not... 19.5 I understand, but 19.6 I don't.
If very few non-show-stoppers from 19.4 have been fixed in 19.5, I
don't see why it would be unstable enough to require a 19.6.  Good to
bring all the packages up to the latest and greatest, but I don't see
any other purpose in 19.5.

If 20.0 is almost as stable, as small or smaller, and as fast or
faster, I don't see why you would even consider a 19.6.

The .elc compatibility problem has me a little concerned for a general
release of 20.0: are the non-mule elc's acceptable to mule or are they
mutually incompatable?  What about compatability with FSF?

My vote would be for a rock-solid (or at least well-tested) 19.5 ASAP
including notice that this is the last of that line and that package
maintainers should be prepared for 20.0 in mid-early February.

../Dave

(I'll build a 19.5 as soon as we have enough disk-space, but this is a
vanilla Solaris 2.5 system with gcc, so it probably won't help much.)

