From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: C-g crash in C-x C-f (OSX Lion) Date: Sat, 24 Dec 2011 10:54:06 +0900 Organization: Faculty of Science, Chiba University Message-ID: 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 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1324691661 25917 80.91.229.12 (24 Dec 2011 01:54:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 24 Dec 2011 01:54:21 +0000 (UTC) Cc: Carsten Mattner , Emacs developers To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 24 02:54:17 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 1ReGoS-0002jo-Sy for ged-emacs-devel@m.gmane.org; Sat, 24 Dec 2011 02:54:17 +0100 Original-Received: from localhost ([::1]:39085 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ReGoS-0003hR-66 for ged-emacs-devel@m.gmane.org; Fri, 23 Dec 2011 20:54:16 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:36177) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ReGoQ-0003hH-0R for emacs-devel@gnu.org; Fri, 23 Dec 2011 20:54:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ReGoO-0002j6-ID for emacs-devel@gnu.org; Fri, 23 Dec 2011 20:54:13 -0500 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:53855) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ReGoO-0002i0-3U for emacs-devel@gnu.org; Fri, 23 Dec 2011 20:54:12 -0500 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 9383AC055D; Sat, 24 Dec 2011 10:54:06 +0900 (JST) In-Reply-To: <6F793ECE-97CA-4CB9-9F7F-C141FE825E3F@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-operating-system: by eggs.gnu.org: NetBSD 3.0 (DF) X-Received-From: 133.82.132.2 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:146950 Archived-At: >>>>> On Fri, 23 Dec 2011 09:09:56 +0100, Jan Dj=E4rv = said: >>>>> 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. > 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? >>=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. > 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 mituharu@math.s.chiba-u.ac.jp