At Mon, 01 Dec 2008 21:43:01 -0500,
Chong Yidong wrote:
>
> We are getting pretty close, and currently there are two main things
> to do before starting the pretest: adding ruby-mode to the CVS
> repository, and making rmail-mbox/pmail ready for use.
I don't know what is the Emacs maintainers' opinion about the GNUstep
port wrt release status/goals, but I'd like to mention that in its
current form it is not usable as a replacement of GTK+/Lucid/nox.
Maybe this is not a problem in general, as probably the main goal of
the port is to make Emacs available for users of the Muck OS X system
(as a replacement of the Carbon port).
I don't see it this way, though, although I realize I'm in the
minority. As a GNUstep user my goal is to use Emacs.app as a
replacement of the Lucid build (or the GTK+ build with the GTK-Step
GTK theme). This is not possible now, even with my extremely low
Emacs usage requirements.
Whether this is considered release-critical is up to the Emacs
maintainers to decide, naturally.
The trouble is that if GNUstep users don't find this flavor usable to
run it by default, bugs will not be even discovered, let alone fixed.
Of course, it is impossible to fix all bugs in time for the 23
release, but at least the most critical ones should be nailed.
Here is a short summary of what I consider important for the GNUstep
port (in my capacity as a humble user). I am still experimenting with
some of the bugs to which Adrian sent useful comments.
* #1333: Emacs.app does not load ~/.emacs
The consequences of this are a real disaster. Emacs also doesn't
inherit the environment, which in many cases makes usage of external
processes a PITA.
* #984: Emacs.app segfaults on startup with the cairo backend
The cairo backend is still considered experimental in GNUstep Back,
although probably 90% of the people are using it, because rendering
is faster and much more beautiful than art. Not being able to use
Emacs with cairo means "downgrading" to art, as it is not possible
to define the backend on a per-app basis (and that's how it should
be). This is a GNUstep problem, I think.
* #620: Bootstrapping with the GNUstep port impossible
Distro unfriendliness. This is not a problem for regular users, as
released Emacs already contains byte-compiled files, and there is an
easy workaround for bootstrapping anyway. However, nowadays the
majority of the users prefer distro-provided packages. Among the
distros who care about GNUstep and ship it, Emacs.app currently
cannot be provided for Gentoo because of this, and for Debian
(gNewSense actually) I am doing a horrible hack/workaround that
no sane (Debian) maintainer would upload as an official package.
As a result, I suspect that at the end this port will have even less
testing.
* Some GNU Coding Standards violations that I'm going to report soon
(with patches, eventually). The problem, basically, is that the
Emacs.app build system breaks certain user expectations that were in
place since about forever.
I hope that even intrusive patches for the GNUstep port will be
accepted in the pretest period.