Re: [PATCH] bookmark.el of edit-utils 1.43 (completing-read usage error)
Valdis Kl=?iso8859-4?Q?=BA?=tnieks
Wednesday, 19 January
2000
Wed, 19 Jan
'00
10:28 a.m.
On Wed, 19 Jan 2000 08:45:06 +0100, Hrvoje Niksic said:
Adrian Aichner <aichner(a)ecf.teradyne.com> writes:
> Doing it right (following Kyle's suggestion) would in this
> particular case lead to awkward code bloat compared to the version
> before Yoshiki's patch. The new feature of `completing-read', the
> DEFAULT argument, cannot be relied upon (because XEmacs-21.1.8 does
> not have it).
Sorry, I don't agree with "cannot be relied upon" part. Backward
compatibility is a nice thing, but can't we just have the new version
of the package support the new XEmacs?
Yes, but with a cost..
I dislike the idea of our packages avoiding using our new features
because of compatibility with old XEmacsen that need to be run with
these very same packages. If the package system can't new packages
requiring new features, then the package system needs fixing.
It's not a question of the package system.. The issue is the 'awkward
code bloat' that Adrian mentions. At some point, you have to just
say "screw it, Foobar-1.19 wirls on 21.2.19 and laoter only, you
21.1 users are stuck with Foobar-1.18", or you have to endure code
that keeps accumulating more and more (if featurep()) code all over
the place.
For an interesting time, cd to xemacs-packages/lisp, and try this:
find . -name '*.el' | xargs grep -i lucid | more
And look how many places we're STILL checking for Lucid
emacs (altthough to be fair, it's usually (string-match "XEmacs\\|Lucid"
emacs-version)
as the test).
calc/calc.el even contains this:
./calc/calc.el: (error "Lucid Emacs requires RET after %s"
And *how* long ago was Lucid? ;)
Is the byte-compiler optimizer able to remove dead code, so at least we're not
taking a performance hit on those?
/Valdis