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: merging Emacs.app Date: Mon, 10 Mar 2008 19:48:23 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <18375.18663.981150.252393@kahikatea.snap.net.nz> <200803031629.m23GT4tH023615@sallyv1.ics.uci.edu> <200803050504.m2554JRn010804@sallyv1.ics.uci.edu> <200803051605.m25G5bfF012539@sallyv1.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1205146166 30668 80.91.229.12 (10 Mar 2008 10:49:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Mar 2008 10:49:26 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 10 11:49:54 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JYfZp-000664-2Q for ged-emacs-devel@m.gmane.org; Mon, 10 Mar 2008 11:49:53 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JYfZG-0008NS-TY for ged-emacs-devel@m.gmane.org; Mon, 10 Mar 2008 06:49:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JYfYX-0008AM-Ma for emacs-devel@gnu.org; Mon, 10 Mar 2008 06:48:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JYfYU-00088K-Ho for emacs-devel@gnu.org; Mon, 10 Mar 2008 06:48:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JYfYT-00088B-VF for emacs-devel@gnu.org; Mon, 10 Mar 2008 06:48:30 -0400 Original-Received: from ntp.math.s.chiba-u.ac.jp ([133.82.132.2] helo=mathmail.math.s.chiba-u.ac.jp) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JYfYT-00017h-8Y for emacs-devel@gnu.org; Mon, 10 Mar 2008 06:48:29 -0400 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 AAF112C43 for ; Mon, 10 Mar 2008 19:48:23 +0900 (JST) In-Reply-To: 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/23.0.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-kernel: by monty-python.gnu.org: NetBSD 3.0 (DF) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:92021 Archived-At: >>>>> On Mon, 10 Mar 2008 10:06:22 +0000 (UTC), Adrian Robert said: >> One may think that the two ports mainly differs in the APIs they >> use, but what's really different between them is their fundamental >> design and policy. (Otherwise I wouldn't have tried to make >> another Cocoa-based port.) >> >> For example, the latest release of Emacs.app still doesn't quit >> with C-g in certain situations such as `(while t)' or `M-! sleep 30 >> RET'. Of course the Carbon port can quit there, but its strategy >> is not directly applicable to the Cocoa port because of the >> difference in their fundamental design. > It is true that there are design differences btwn the ports, many > arising because NeXTstep is an OO API and the port tried to use > those facilities effectively from the beginning. (And there are > pros and cons of this, since it causes some code differences to > other ports built around non-OO APIs.) However that is unrelated to > this Ctrl-G issue. I don't mean OO vs. non-OO, which is of course unrelated to C-g, by "difference in their fundamental design". > The event handling in the Emacs.app is slightly different from the > Carbon code, but in my understanding these shouldn't prevent similar > Ctrl-G sensitivity. However by default Emacs.app does not define > NO_SOCK_SIGIO, while Carbon does. Turning it on (add > --enable-cocoa-experimental-ctrl- g to configure args) improves > Ctrl-G sensitivity, but brings some undesired side effects, related > to scrolling and multi-frame switching. It is an open TODO to > address these side effects and also make a few other code changes to > bring the sensitivity fully up to the Carbon level, but I would be > surprised if it needed changes to fundamental design to do this. I can find so many (indirect) Feval calls from ns_read_socket and some of them seem to be difficult to get rid of because of its fundamental design. In Emacs 22 at least, read_socket_hook may be called from a signal handler in most environments. As the Lisp interpreter is not designed to be reentrant, you cannot call Feval from read_socket_hook directly or indirectly (that's why both X11 and Carbon ports increment `handling_signal' in their read_socket_hook's to make Feval abort). You don't see such a problem in the Cocoa/GNUstep port unless NO_SOCK_SIGIO is defined, but C-g is not handled properly. I'm not sure if SYNC_INPUT changes the situation in Emacs 23. But I would rather choose the strategy that is working in other platforms than taking a risk of introducing a untested one for nontrivial issues such as C-g. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp