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: emacsclient's option decoding code Date: Wed, 12 Nov 2008 12:13:13 -0500 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1226510022 5069 80.91.229.12 (12 Nov 2008 17:13:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Nov 2008 17:13:42 +0000 (UTC) Cc: Eli Zaretskii , cyd@stupidchicken.com, emacs-devel@gnu.org To: "Juanma Barranquero" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 12 18:14:42 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 1L0JIb-0007SJ-90 for ged-emacs-devel@m.gmane.org; Wed, 12 Nov 2008 18:14:37 +0100 Original-Received: from localhost ([127.0.0.1]:55801 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L0JHT-0007Mf-7G for ged-emacs-devel@m.gmane.org; Wed, 12 Nov 2008 12:13:27 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L0JHL-0007Ko-OJ for emacs-devel@gnu.org; Wed, 12 Nov 2008 12:13:19 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L0JHK-0007K4-84 for emacs-devel@gnu.org; Wed, 12 Nov 2008 12:13:19 -0500 Original-Received: from [199.232.76.173] (port=52869 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L0JHJ-0007Jy-UI for emacs-devel@gnu.org; Wed, 12 Nov 2008 12:13:17 -0500 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]:24720 helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L0JHI-0001Jl-Hk; Wed, 12 Nov 2008 12:13:16 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAKidGklFxLQU/2dsb2JhbACBds46g1eBEQ X-IronPort-AV: E=Sophos;i="4.33,591,1220241600"; d="scan'208";a="29776471" Original-Received: from 69-196-180-20.dsl.teksavvy.com (HELO pastel.home) ([69.196.180.20]) by ironport2-out.teksavvy.com with ESMTP; 12 Nov 2008 12:13:15 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id C8AA484CE; Wed, 12 Nov 2008 12:13:13 -0500 (EST) In-Reply-To: (Juanma Barranquero's message of "Wed, 12 Nov 2008 17:37:53 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:105605 Archived-At: > Fine by me. Someday, if multi-GUI materializes, we'll have to add a > frame parameter or another way for lisp code to query the GUI > associated with a given frame. framep is a built-in function in `C source code'. (framep object) Return non-nil if object is a frame. Value is t for a termcap frame (a character-only terminal), `x' for an Emacs frame that is really an X window, `w32' for an Emacs frame that is a window on MS-Windows display, `ns' for an Emacs frame on a GNUstep or Macintosh Cocoa display, `pc' for a direct-write MS-DOS frame. See also `frame-live-p'. > - Should the "-c + no DISPLAY" => "-t" implication of emacsclient be > removed only for Windows (because it does in fact make sense on > POSIX), or be removed for good (Eli's view, I think)? It's there for Unix where it makes sense. We can remove it for Windows until we know how to implement -t there. > - Do I change term/w32-win.el to use ":0.0" as argument to > `x-open-connection'? I'd leave it as "" for now. > - If yes, do we leave `make-frame-on-display' as it stands now, i.e. > accepting any DISPLAY string as valid when called from Windows, or do > we change it to accept just ":0.0" for the time being? (I favor the > second, which is simpler and cleaner: it's just removing the recent > three-line patch by Chong.) Yes, we should change it to only accept "", tho I'm not sure if it will re-introduce the bug that was fixed by Chong's patch. > - Do we want `make-frame-on-display' to accept a null DISPLAY (on > every platform) to mean "create a frame on the current display"? I don't see any reason why we'd want that since (frame-parameter nil 'display) already works just fine for that purpose and says clearly what it is doing. Stefan