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

[Jan Djärv]

24 dec 2011 kl. 02:54 skrev YAMAMOTO Mitsuharu:

>>>>>> On Fri, 23 Dec 2011 09:09:56 +0100, Jan Djärv <address@hidden> said:
> 
>>>>>> Most of the uses of the Carbon framework in the Mac port are for
>>>>>> Apple Events and Carbon Events.
>>>>> 
>>>>> The main purpose of the use of them is to avoid Lisp evaluation
>>>>> inside read_socket_hook.
> 
>> 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).

>  (BTW, I found that the position of the `Buffers' menu is
> strange on the NS port.)
> 

This must be a bug.

>>>> No way to make that work similarly without Carbon?
>>> 
>>> As far as I know.  I actually tried that at the very early stage of
>>> the development of the predecessor of the Mac port.
> 
>> I'm not sure what the problem is, but couldn't Core Foundation be
>> used?
> 
> I don't think so.  But maybe you have some (rough) idea?  It doesn't
> make sense to avoid 64-bit Carbon for the Mac port, but it might be
> useful for the NS port.  (I'm not sure whether Core Foundation is also
> available on GNUstep.)

There are some nice things (like CFFileDescriptor) in CoreFoundation that isn't 
available at the Cocoa level.  It just occured to me that something useful 
could be found here.  CoreFoundation is not available for GnuStep.

        Jan D.