emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: YAMAMOTO Mitsuharu
Subject: Re: C-g crash in C-x C-f (OSX Lion)
Date: Sat, 24 Dec 2011 10:54:06 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> 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.  (BTW, I found that the position of the `Buffers' menu is
strange on the NS port.)

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

                                     YAMAMOTO Mitsuharu
                                address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]