Re: merging Emacs.app

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 10 Mar 2008 10:06:22 +0000 (UTC), Adrian Robert <address@hidden> 
>>>>> said:

>> One may think that the two ports mainly differs in the APIs they
>> use, but what's really different between them is their fundamental
>> design and policy.  (Otherwise I wouldn't have tried to make
>> another Cocoa-based port.)
>> 
>> For example, the latest release of Emacs.app still doesn't quit
>> with C-g in certain situations such as `(while t)' or `M-! sleep 30
>> RET'.  Of course the Carbon port can quit there, but its strategy
>> is not directly applicable to the Cocoa port because of the
>> difference in their fundamental design.

> It is true that there are design differences btwn the ports, many
> arising because NeXTstep is an OO API and the port tried to use
> those facilities effectively from the beginning.  (And there are
> pros and cons of this, since it causes some code differences to
> other ports built around non-OO APIs.)  However that is unrelated to
> this Ctrl-G issue.

I don't mean OO vs. non-OO, which is of course unrelated to C-g, by
"difference in their fundamental design".

> The event handling in the Emacs.app is slightly different from the
> Carbon code, but in my understanding these shouldn't prevent similar
> Ctrl-G sensitivity.  However by default Emacs.app does not define
> NO_SOCK_SIGIO, while Carbon does.  Turning it on (add
> --enable-cocoa-experimental-ctrl- g to configure args) improves
> Ctrl-G sensitivity, but brings some undesired side effects, related
> to scrolling and multi-frame switching.  It is an open TODO to
> address these side effects and also make a few other code changes to
> bring the sensitivity fully up to the Carbon level, but I would be
> surprised if it needed changes to fundamental design to do this.

I can find so many (indirect) Feval calls from ns_read_socket and some
of them seem to be difficult to get rid of because of its fundamental
design.  In Emacs 22 at least, read_socket_hook may be called from a
signal handler in most environments.  As the Lisp interpreter is not
designed to be reentrant, you cannot call Feval from read_socket_hook
directly or indirectly (that's why both X11 and Carbon ports increment
`handling_signal' in their read_socket_hook's to make Feval abort).
You don't see such a problem in the Cocoa/GNUstep port unless
NO_SOCK_SIGIO is defined, but C-g is not handled properly.

I'm not sure if SYNC_INPUT changes the situation in Emacs 23.  But I
would rather choose the strategy that is working in other platforms
than taking a risk of introducing a untested one for nontrivial issues
such as C-g.

                                     YAMAMOTO Mitsuharu
                                address@hidden