Re: Emacs on OS X development

["Jan Djärv" <jan.h.d@swipnet.se>]

Hello.

23 jul 2012 kl. 21:45 skrev John Wiegley:

>>>>>> Stefan Monnier <monnier@IRO.UMontreal.CA> 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.

Bugs do get fixed in the NS port.  I use it on OSX every weekday (at work), so I try to fix bugs.  Others do too from time to time.  In the last 6 months or so, I'd say that the NS port has gotten as much attention as the Gtk+ port.  Granted that the NS-port may have had more problems to begin with.

> 
> 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?

It depends on what you mean by moving forwards.  As has been stated, many people use the NS port (myself included) without the problems others seem to have.  I have tried hard to come up with a crash or a display corruption, but so far failed, with the exception of 11484.  But I haven't have time to fix that yet.  

It may seem to you as nothing is done about the problems you face, but so far nobody has been able to come up with a single case that is reproducable by someone that may fix ns-port bugs.  Not even 11541, 11684 or 11792 craches for me, and I have tried all sorts of compiler and configuration options.

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

I don't see how seeing a bug in the NS-port stops you from providing a fix to that bug.

> 
> 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"

How do you set this font? In .emacs, in default-frame-alist, via customize, via the font dialog?

Locale and system language probably also has something to do with the problems.

Does compiling emacs with just --with-ns give you any different results (w.r.t. craches as in 11541, 11684 or 11792 , the slowdown below will presist)?

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

This is a known issue, partly to do with how the event loop is implemented.  A smarter loop doubles the speed, but it is still slower than say X.

	Jan D.