From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?iso-8859-1?Q?Jan_Dj=E4rv?= Newsgroups: gmane.emacs.devel Subject: Re: C-g crash in C-x C-f (OSX Lion) Date: Mon, 26 Dec 2011 16:31:12 +0100 Message-ID: <61A2186E-2D7D-419B-8813-D8ACB733DE70@swipnet.se> References: <4EEB48B2.9090602@swipnet.se> <83liqc1tac.fsf@gnu.org> <83fwgk1atk.fsf@gnu.org> <4EEBE0DC.1050803@cs.ucla.edu> < 4EEF5DF5.3030506@swipnet.se> <9E637EAB-A0C5-421B-9CCA-71C41442AF52@gmail.com> <6F793ECE-97CA-4CB9-9F7F-C141FE825E3F@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1324913487 13439 80.91.229.12 (26 Dec 2011 15:31:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 26 Dec 2011 15:31:27 +0000 (UTC) Cc: Carsten Mattner , Emacs developers To: YAMAMOTO Mitsuharu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 26 16:31:22 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RfCWH-0001sm-6y for ged-emacs-devel@m.gmane.org; Mon, 26 Dec 2011 16:31:21 +0100 Original-Received: from localhost ([::1]:51333 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RfCWG-0000es-Nk for ged-emacs-devel@m.gmane.org; Mon, 26 Dec 2011 10:31:20 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:36317) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RfCWE-0000du-CD for emacs-devel@gnu.org; Mon, 26 Dec 2011 10:31:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RfCWD-0000e6-4v for emacs-devel@gnu.org; Mon, 26 Dec 2011 10:31:18 -0500 Original-Received: from mailout.melmac.se ([62.20.26.67]:43668) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RfCWC-0000dw-Pl for emacs-devel@gnu.org; Mon, 26 Dec 2011 10:31:17 -0500 Original-Received: from mail01.melmac.se (mail01.melmac.se [62.20.26.80]) by mailout.melmac.se (Postfix) with ESMTP id DE829994B for ; Mon, 26 Dec 2011 16:31:15 +0100 (CET) Original-Received: (qmail 27794 invoked by uid 89); 26 Dec 2011 15:30:24 -0000 Original-Received: from h-46-59-42-18.na.cust.bahnhof.se (HELO coolsville.localdomain) (boel.djarv@bdtv.se@46.59.42.18) by mail01.melmac.se with ESMTPA; 26 Dec 2011 15:30:24 -0000 Original-Received: from [172.20.199.14] (zeplinf [172.20.199.14]) by coolsville.localdomain (Postfix) with ESMTPSA id CD3497FA058; Mon, 26 Dec 2011 16:31:12 +0100 (CET) In-Reply-To: X-Mailer: Apple Mail (2.1251.1) X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 62.20.26.67 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:146971 Archived-At: 24 dec 2011 kl. 02:54 skrev YAMAMOTO Mitsuharu: >>>>>> On Fri, 23 Dec 2011 09:09:56 +0100, Jan Dj=E4rv = said: >=20 >>>>>> Most of the uses of the Carbon framework in the Mac port are for >>>>>> Apple Events and Carbon Events. >>>>>=20 >>>>> The main purpose of the use of them is to avoid Lisp evaluation >>>>> inside read_socket_hook. >=20 >> Are you saying the Cocoa port runs lisp inside read_socket_hook? >> Can you show where that is done? >=20 > I wrote about that in > http://lists.gnu.org/archive/html/emacs-devel/2009-01/msg00952.html : >=20 > 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. >=20 > 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. >=20 > 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.) >=20 This must be a bug. >>>> No way to make that work similarly without Carbon? >>>=20 >>> As far as I know. I actually tried that at the very early stage of >>> the development of the predecessor of the Mac port. >=20 >> I'm not sure what the problem is, but couldn't Core Foundation be >> used? >=20 > 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.