SL Baur writes:
Colin Rafferty <craffert(a)ms.com> writes in
xemacs-beta(a)xemacs.org:
> Didier Verna writes:
>> This patch avoids using extent-data, a function that is
obsolete at
>> least from XEmacs 20.3 and will completely disapear in XEmacs 21.2
>> and later.
>> [... s/extent-data/extent-property/g ...]
> In which version of XEmacs did `extent-property' get created?
It has always been in XEmacs and `extent-data' has always been
obsolete
in XEmacs (ie. since at least XEmacs 19.11). I don't have Lucid Emacs
sources untarred, so I don't know how much earlier it was present.
Well, I just discovered the same thing myself. I guess the original
author didn't believe in compiler warnings.
Basically, any version of XEmacs is O.K. Any version of Lucid Emacs
might not be.
I think that we can safely dump 19.10 support, even though it's
mentioned in the source. In fact, I think that BBDB 2 already fails
under 19.10. I wish I had an executable to test.
> We're trying to be backwards-compatible, so I need to know
whether to
> apply the patch as-is, or do a song-and-dance function.
O.K. But look at the more complete patch I sent in which changes
all
the obsolete symbols not just the one Didier changed.
I didn't notice that this was a subset of your original patch. I'll
see about incorporating your patch.
Speaking of backwards compatibility, I don't like the way the
XEmacs
M-TAB binding for `ispell-complete-word' gets overwritten by BBDB 2.
Neither do I, but I didn't notice it until just now.
I think the concept is fine, but I would rather have a pointer to
message-x (or better, a (condition-case nil (require 'message-x) ...)),
and do away with the `define-key' altogether).
--
Colin