"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)xemacs.org> writes:
Hrvoje> If that's fine with you, it's certainly fine with me. We
Hrvoje> used to insist that the general public use and the Linux
Hrvoje> distros ship stable versions, but I understand if that
Hrvoje> changed to reflect the new reality.
Well, I'd like to see non-developers using the stable release, but
basically it's not reasonable to restrict them to that.
For one thing, several leading GNU developers openly deprecate the
stable release of GNU Emacs (specifically David Kastrup, but even
cooler heads like Stefan Monnier admit that for their purposes
stable Emacs is not really usable); in practice, anybody who wants
to use advanced features of AUCTeX or any of the GDB-related modes
must use CVS Emacs.
Well, that does not necessarily mean that you have to join the arms
race of non-release embarrassment.
But XEmacs 21.4 isn't even close to synched to stable GNU Emacs,
let
alone capable of emulating features of CVS GNU Emacs.
I don't think that there is a significant number of features to
emulate. There are serious improvements in the realm of indenting,
filling and syntax highlighting worthy of synching. But those are
mostly not new features, but improvements of previous stuff. The
display engine is much improved with regard to tall images and
scrolling and stuff, but since the code is completely different from
XEmacs, that is no concern for synching.
A _large_ number of optional modes and packages have been
significantly improved. Synching them does not actually require
waiting for the "main" stuff: that's what the package system is
supposed to be good for. Unfortunately, you are missing the manpower
to actually make use of the distributed maintenance that your package
system is supposed to facilitate.
And then there's the Unicode issue.
Yes. XEmacs 21.4 does not cut it, and from what I hear, XEmacs 21.5
does not cut it yet. It might see the light of day as a stable
release earlier than Emacs 23 (which is supposed to use utf-8 for its
internal encodings too), but even though the _performance_ of Emacs 22
on large utf-8 files leaves something to be desired, its interaction
with files and environment is rather smooth and usable for GNU/Linux
distributions using utf-8 by default (most of them by now, and most
other Unix-like environments are following suit).
And finally, we are once again in the situation we were in in Sept
2000, with an excellent but aging stable line and no schedule for a
release of the devel codebase.
Realistically, we have to welcome any interest from *nix distros at
this stage.
Debian unstable by now carries emacs-snapshot packages. Go figure.
However, they are IIRC orthogonal to the stable Emacs packages, so you
can install both at the same time.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum