Re: C-g crash in C-x C-f (OSX Lion)

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 26 Dec 2011 16:31:12 +0100, Jan Djärv <address@hidden> said:

>>> Are you saying the Cocoa port runs lisp inside read_socket_hook?
>>> Can you show where that is done?
>> 
>> I wrote about that in
>> http://lists.gnu.org/archive/html/emacs-devel/2009-01/msg00952.html
>> :
>> 
>> In the platforms other than the Cocoa/GNUstep port, menu bar is
>> uniformly activated by the x_activate_menubar call in
>> kbd_buffer_get_event, which is called from read_char.  However, the
>> Cocoa/GNUstep port activates the menu bar and starts mouse tracking
>> in the context of read_socket_hook, which is supposed to be called
>> from fairly random states of the Lisp interpreter.
>> 
>> The current NS port is trying to minimize the problem by
>> disallowing Lisp evaluations from QUIT and UNBLOCK_INPUT (grep
>> `handling_signal' in the NS specific code including those enclosed
>> with #ifdef HAVE_NS).  I don't know if that could avoid all the
>> problems, or some of unsolved problems on the NS port are caused by
>> this.  Anyway, I would choose keeping the fundamental design
>> principle and did so in the Mac port.
>> 
>> Allowing menu bar activation while disallowing Lisp evaluations in
>> read_socket_hook from QUIT/UNBLOCK_INPUT also causes a bogus menu
>> bar problem: one can start menu bar tracking even during the
>> evaluation of (while t), whereas the contents of the `Buffers' menu
>> would possibly be outdated.

> This can be fixed in Cocoa, but OSX 10.5 or later is required (AFAIK
> anyway).

That'll be good.  When I first tried porting the GUI part to Cocoa,
the newest version of Mac OS X was 10.4, so I couldn't use the way you
are talking about.  (It was a bit after the announcement that Carbon
GUI will not support 64-bit on coming Mac OS X 10.5.)  Even after the
10.5 release, I couldn't have dropped the support for the older
versions.

                                     YAMAMOTO Mitsuharu
                                address@hidden