Re: Obsolescence -- I like `eval-current-buffer'

Hrvoje Niksic <hniksic(a)srce.hr&gt; writes: Ah, I suppose I should have checked that. The current policy being enforced is this: 1. If a symbol in XEmacs has been renamed, but the old name exists and is in active usage in FSF Emacs, it is (make-compatible)'d where it was previously (make-obsolete)'ed. These are mostly done, but some symbols have fallen through the cracks, like `eval-current-buffer'. I do not want package authors turning off bytecompiler warnings due to obsolescence warnings from the bytecompiler due to portability with FSF Emacs. I consider this an XEmacs bug to be fixed. 2. If a symbol has been obsoleted in ancient versions of Emacs (ie. Emacs 18, Lucid Emacs, XEmacs pre-19.12) it will be deleted now. 3. If a symbol has been obsoleted at least three years and is not in active usage it will be deleted. 4. Other symbols that have long (long == >= 3 years) been obsolete are candidates for reassignment. The best example of this is `lisp-indent-hook'. It has been obsolete for ages, however it is still more widely used than its replacement `lisp-indent-function'. Maybe in 22.0 it could be changed. At the moment I fail to see the point. I am serious about XEmacs 21 signaling "The bloat stops here." XEmacs shall not be the prime example of a huge, bloated pig of a piece of software. Deleting stuff no one has used, and the editor has signalled for years as being on the verge of imminent deletion definitely counts. We've been doing very well on the performance side. I've received numerous comments to the effect that while XEmacs has always been a huge drain of system resources it *has not* steadily increased its draw on resources and is both getting natively faster and getting better hardware to run on. The combination of which has meant that XEmacs is getting *much* faster than people are used to. This is Good. Thanks to Ben, the non-Mule XEmacs has no Mule baggage to carry around. This is also Good. Hopefully, as the MS Windows port matures there will be little need in the near future for NTemacs as well. I've gotten kind of cranky in the last couple of weeks as my nose has been pushed in the fact that XEmacs 21.0 is going to really suck. For that I apologize. It's not the end of the world, there will be another version of XEmacs after it. I've opened 21.2 and 22.0 development trees so bleeding edge development can occur and get patched into XEmacs development source trees while the problems of 21.0 are worked out over the Summer.