Re: Emacs on OS X development

[John Wiegley]

>>>>> Stefan Monnier <address@hidden> writes:

> None of that is inherent, i.e. it can all be fixed without having to use a
> different API.  So we need to someone to step up to the plate and provide
> patches.

We have an existing body of code that it seems no one is excited to maintain,
and a fork that at least one person is very eager to maintain.

Is the correct answer to say that we're not moving forward until someone gains
interest in something currently unexciting?  Or should we migrate to a
code-base where we have a guaranteed active developer?

Waiting until NS finds its star developer does not seem like a real strategy
to me -- unless you don't have a problem with NS currently.  But this is a
genuine issue for many of us.  It prevents me, personally, from following
trunk and providing fixes/bug reports relative to trunk.

Simply because non-OS X users don't seem to care what happens on OS X, doesn't
mean it should be this easy to ignore the problem.  It hasn't "gone away" in a
few years now, and I don't see why that's suddenly going to change now.

Can everyone who has issues with NS please help by gathering data about your
environment and use cases?  The problems I have manifest even with -Q.  I
build as follows:

  configure --with-ns --enable-checking --enable-check-lisp-object-type
            --prefix=$INSTALL_DIR CC=clang CXX=clang++ LD=clang
            CFLAGS='-g -O0 -fno-omit-frame-pointer'
            LDFLAGS="$CFLAGS"

I then change my font to:

  "-*-Courier-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1"

When in a scratch buffer, if I enable flyspell-mode, I can type fast enough
that Emacs can't insert the characters as quickly as I can type.

It's this last problem that makes the NS port entirely unusable to me.  The
poor font rendering (at least of Courier) is mostly cosmetic.

John