Re: Release candidate for XEmacs 21.4.4 / my vacation

|--==> "SJT" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp&gt; writes: APA> Can I do anything to get this feature in? SJT> Ben sez, just add the Lisp code to init.el. Alternatively, you could SJT> make a package, which people could require in init.el. Then when we SJT> get it fixed, we have core XEmacs provide the same symbol and the SJT> package will just wither away. SJT> With a little care, it could be a generic solution: the package would SJT> be "lisp-updates" or some such. Each separate fix would have its own SJT> feature. I suppose we'd need to make the feature "list" into a SJT> hash-table because these would probably accumulate pretty quickly. SJT> Alternatively, we could obsolete the symbols with every major release SJT> (so there would be "lisp-updates-21.1" and so on). SJT> What do you think, Steve? This would really make life nicer for the SJT> users and easier for the core maintainers, but it definitely increases SJT> the burden on you---these packages could end up being quite large. You know what they say, "...it's not the size that counts, but how you use it...". Large packages aren't that much of a concern to me because the people who write them will take care of any bugs in them. :-) What does concern me is that this Feature-Package[tm] would be very version specific. I would insist that this package goes out of its way to bend over backwards and jump through hoops to test for the XEmacs version and to do the right thing accordingly. It would mean that if a new version of XEmacs is released that still doesn't have the new "features" of the Feature-Package[tm], then of course, the Feature-Package[tm] will have to be updated as well. Otherwise all hell will break out on c.e.x and I'll start getting hate email from disgruntled users. :-( -- |---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|