Re: Release update

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> 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).

The GNUstep port is not release-critical for Emacs-23.1.  I do think
it's an important target, so it might become release-ciritcal for
Emacs-23.2, but I just don't think it's worth delaying a release for it,
given its current status.

> * #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.

I have the nagging feeling that this is linked to the
CANNOT_DUMP problem.  So it's probably better to spend time on getting
DUMP to work.

> * #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.

No idea about this.

> * 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.

Awaiting your patches.

> I hope that even intrusive patches for the GNUstep port will be
> accepted in the pretest period.

Patches that only affect GNUstep can be about as intrusive as they want,
yes (as long as they move forward, obviously), since the port is barely
usable anyway.


        Stefan