Re: Emacs on OS X development

[Chong Yidong <cyd@gnu.org>]

John Wiegley <johnw@newartisans.com> writes:

>>>>>> Jan Djärv <jan.h.d@swipnet.se> writes:
>
>> I think that for the Emacs project it is more important to support
>> other GNU projects than to make the best Emacs we can on non-GNU
>> platforms.  That is my impression at least.
>
> I think this is a really bad precedent to set.  By making Emacs
> inferior to benefit the GNU project, I think we hurt Emacs more than
> we benefit GNU.
>
> If GNU needs so much help that we should sacrifice the excellence of
> Emacs at its altar, that speaks volumes right there.

This is an old, old argument that I have zero interest in re-hashing.

Look, no one is saying that you're not allowed to improve the Mac OS
part of the Nextstep port, or that the GNUstep part must must work
exactly as well as the Mac OS part.  On the contrary; if you want to
help improve it, go right ahead.

Here's the historical context.  Way back during the Emacs 23 development
cycle, the Carbon port was completely broken; it could not even compile.
It remained so for a period of (IIRC) almost a year, because Yamamoto
Mitsuharu was at the time unwilling to keep it up to date with the
changes to the terminal and font systems, and apparently no one else
could fix it.  Since the Cocoa port was in the process of being merged,
it was then decided that rather than keep two Mac ports---one of them
broken for the indefinite future---we'd just go with Cocoa and work on
improving it.

As a significant bonus, the Cocoa port would, if whipped into shape,
provide GNUstep support along the way.

Since then, of course, Yamamoto Mitsuharu has been able to keep the
Carbon port alive.  More power to him, and great for those users who
like that alternative.  But AFAICT he's happy to follow his own timing.
For instance, for a long period of time during the Emacs 24 cycle, the
Mac port was purely 23-only.

Hence the decision made during the Emacs 23 pretest remains valid.
There's no point including two Mac ports in the tree, with all the
attendant demands on documentation and bug reporting, especially if one
of those ports keeps going in and out of sync with the rest of Emacs
based on when its maintainer decides to update it.  Having the Mac port
live outside the Emacs tree, under Mitsuharu's control, is an amicable
compromise.

Now, the problem is that the quality of the Cocoa port has not been
improving as quickly as I'd like.  But this is essentially because most
active Emacs hackers don't work on Mac OS, and those that do are
interested in working on stuff other than the Cocoa code.  Maybe somehow
it's impossible to improve the Cocoa port to get it to work as well as
the Carbon port (or at least the Carbon port when the stars are aligned
and it's in sync with the development tip).  But we are engaged in
software programming, not magic!  There's nothing that can't be fixed,
if someone steps up to the plate to fix it.  Even if there are
fundamental problems with the Cocoa port, if anyone would like to
propose big code changes to fix those flaws, we're perfectly happy to
consider/accept them.