From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: a review of the merge (Re: Emacs.app merged) Date: Wed, 16 Jul 2008 12:21:17 -0400 Message-ID: References: <1C66F1FC-BF82-4365-944D-ADCC4D1F435C@gmail.com> <200807160925.m6G9PuVj012462@sallyv1.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1216225355 21877 80.91.229.12 (16 Jul 2008 16:22:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Jul 2008 16:22:35 +0000 (UTC) Cc: Adrian Robert , emacs- devel To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 16 18:23:23 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 1KJ9mi-0000G0-SL for ged-emacs-devel@m.gmane.org; Wed, 16 Jul 2008 18:23:21 +0200 Original-Received: from localhost ([127.0.0.1]:35068 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KJ9lq-0002z7-DN for ged-emacs-devel@m.gmane.org; Wed, 16 Jul 2008 12:22:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KJ9ll-0002wS-3I for emacs-devel@gnu.org; Wed, 16 Jul 2008 12:22:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KJ9lk-0002vf-FT for emacs-devel@gnu.org; Wed, 16 Jul 2008 12:22:20 -0400 Original-Received: from [199.232.76.173] (port=45641 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KJ9lk-0002vN-Ba for emacs-devel@gnu.org; Wed, 16 Jul 2008 12:22:20 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:33756) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KJ9lk-0003KT-5l for emacs-devel@gnu.org; Wed, 16 Jul 2008 12:22:20 -0400 Original-Received: from ceviche.home (vpn-132-204-232-63.acd.umontreal.ca [132.204.232.63]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id m6GGMImd008247 for ; Wed, 16 Jul 2008 12:22:18 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id C530CB4097; Wed, 16 Jul 2008 12:21:17 -0400 (EDT) In-Reply-To: <200807160925.m6G9PuVj012462@sallyv1.ics.uci.edu> (Dan Nicolaescu's message of "Wed, 16 Jul 2008 02:25:56 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 3 Rules triggered HAS_X_HELO=0, RV3061=0, XH_GE5=0 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) 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:100817 Archived-At: Thank you Dan for double checking. Adrian, please try and address those issues. > +#if defined(COCOA) > +mac-fix-env: ${srcdir}/mac-fix-env.m > + $(CC) -o mac-fix-env ${srcdir}/mac-fix-env.m -prebind -framework Foundation > +#endif > No need to make it conditional. And shouldn't this use NS_IMPL_COCOA > instead of COCOA? Actually, shouldn't this even check MAC_OSX instead? > Index: lisp/frame.el > =================================================================== > RCS file: /sources/emacs/emacs/lisp/frame.el,v > retrieving revision 1.272 > diff -a -u -r1.272 frame.el > --- lisp/frame.el 12 Jun 2008 03:56:16 -0000 1.272 > +++ lisp/frame.el 15 Jul 2008 16:52:39 -0000 > @@ -610,9 +610,16 @@ > "Make a frame on X display DISPLAY. > The optional second argument PARAMETERS specifies additional frame parameters." > (interactive "sMake frame on display: ") > - (or (string-match "\\`[^:]*:[0-9]+\\(\\.[0-9]+\\)?\\'" display) > - (error "Invalid display, not HOST:SERVER or HOST:SERVER.SCREEN")) > - (when (and (boundp 'x-initialized) (not x-initialized)) > - (setq x-display-name display) > - (x-initialize-window-system)) > - (make-frame `((window-system . x) (display . ,display) . ,parameters))) > + (if (featurep 'ns-windowing) > + (progn > + (when (and (boundp 'ns-initialized) (not ns-initialized)) > + (setq ns-display-name display) > + (ns-initialize-window-system)) > + (make-frame `((window-system . ns) (display . ,display) . ,parameters))) > + (progn > + (or (string-match "\\`[^:]*:[0-9]+\\(\\.[0-9]+\\)?\\'" display) > + (error "Invalid display, not HOST:SERVER or HOST:SERVER.SCREEN")) > + (when (and (boundp 'x-initialized) (not x-initialized)) > + (setq x-display-name display) > + (x-initialize-window-system)) > + (make-frame `((window-system . x) (display . ,display) . ,parameters))))) > Is this necessary? Can NS make frames on another display? If not, > then this should not be needed. I believe GNUstep can. > +(defconst command-line-ns-option-alist > + '(("-NSAutoLaunch" 1 ns-ignore-1-arg) > + ("-NXAutoLaunch" 1 ns-ignore-1-arg) > [snip] > Can this be put somewhere else? It would be better if all other platforms > do not have to load this definition. How do other platforms do it? Shoujld we have a lisp/ns-fns.el where we can put those things? > @@ -8044,7 +8070,12 @@ > && SYMBOLP (XSYMBOL (def)->function) > && ! NILP (Fget (def, Qmenu_alias))) > def = XSYMBOL (def)->function; > +#ifdef HAVE_NS > + /* prefer 'super' bindings */ > + tem = Fwhere_is_internal (def, Qnil, Qsuper, Qt, Qt); > +#else > tem = Fwhere_is_internal (def, Qnil, Qt, Qnil, Qt); > +#endif > Please run this by Stefan, not sure if we want to have a platform do > something different here. I'm looking at it, indeed. > Index: src/keymap.c > =================================================================== > RCS file: /sources/emacs/emacs/src/keymap.c,v > retrieving revision 1.374 > diff -a -u -r1.374 keymap.c > --- src/keymap.c 5 Jun 2008 05:44:11 -0000 1.374 > +++ src/keymap.c 15 Jul 2008 17:01:22 -0000 > @@ -111,3 +111,6 @@ > extern Lisp_Object Voverriding_local_map; > +#ifdef HAVE_NS > +extern Lisp_Object Qalt, Qcontrol, Qhyper, Qmeta, Qsuper; > +#endif > Please get the changes in this file approved by Stefan, they look > a bit suspicious. I think the intention is OK, but it needs to be made generic. This is linked to the above where_is_internal call (and the current "menus are slow" problem). Stefan