From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Juanma Barranquero" Newsgroups: gmane.emacs.devel Subject: Re: emacsclient's option decoding code Date: Wed, 12 Nov 2008 17:37:53 +0100 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1226507901 28942 80.91.229.12 (12 Nov 2008 16:38:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Nov 2008 16:38:21 +0000 (UTC) Cc: Eli Zaretskii , cyd@stupidchicken.com, emacs-devel@gnu.org To: "Stefan Monnier" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 12 17:39:21 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 1L0IkI-00084G-Ni for ged-emacs-devel@m.gmane.org; Wed, 12 Nov 2008 17:39:11 +0100 Original-Received: from localhost ([127.0.0.1]:53672 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L0IjA-0001pU-Pq for ged-emacs-devel@m.gmane.org; Wed, 12 Nov 2008 11:38:00 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L0Ij6-0001mk-3P for emacs-devel@gnu.org; Wed, 12 Nov 2008 11:37:56 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L0Ij5-0001lU-Gv for emacs-devel@gnu.org; Wed, 12 Nov 2008 11:37:55 -0500 Original-Received: from [199.232.76.173] (port=58702 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L0Ij5-0001lO-B0 for emacs-devel@gnu.org; Wed, 12 Nov 2008 11:37:55 -0500 Original-Received: from yw-out-1718.google.com ([74.125.46.156]:28492) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L0Ij4-0000c9-SU for emacs-devel@gnu.org; Wed, 12 Nov 2008 11:37:55 -0500 Original-Received: by yw-out-1718.google.com with SMTP id 9so215547ywk.66 for ; Wed, 12 Nov 2008 08:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Zfja8Lbk5rho8uP+WIVZJBreEgYFRfGElM4ecqaVYoc=; b=JySbg0sTA+5HhuhejfEOHaZLpfwJpnb7eEzGYV6AVI/nPYlC+fyS4UX26LTABUh0Dl MKSuAlXGQpbT7JTDUFIPhTRET0vAl2LsUp8X+qCfdD4rmf4oOsOhE+/txwIxgF2ilSfI pgBD5hvgjApgNYj+GXpLx+dF8xV7u9nNSSmmM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=rLn/gz9XFboPSy1JjYnOj9lH+oRpRpQdUaQUxd1Df55382OaocB3jgmGGNl6lOX1dl W3gJIiOev6cax/RcJmUOMwZd/M6xHMAFAZq/3aXOtzs/qaQYUMpxoma9s69/Xr2AOJMH DApVH7jUZXuGLafZ7sZEw5mA7FsQhP9AJ7sX4= Original-Received: by 10.100.93.17 with SMTP id q17mr4009851anb.104.1226507873118; Wed, 12 Nov 2008 08:37:53 -0800 (PST) Original-Received: by 10.100.13.13 with HTTP; Wed, 12 Nov 2008 08:37:53 -0800 (PST) In-Reply-To: Content-Disposition: inline X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:105604 Archived-At: On Wed, Nov 12, 2008 at 16:56, Stefan Monnier wrote: > You might be right. I tend to think of `display' as something similar > to `terminal', but they're not the same. To tell you the truth, I'm not > sure what `display' is meant for exactly. Same here. I find weird (though perhaps understandable) that Emacs has a clear separation between tty and graphics frames, but not such between X and w32 (and ns, etc.) frames. By that I mean that there is code which calls x-functions when compiled on GNU/Linux, and their w32-* counterparts when compiled on Windows. That will be a problem if someday we have a multi-GUI Emacs. > E.g., let's imagine a w32 version of Emacs which has been hacked to be > able to use X11 as well. And let's additionally say that it can even > also use GNUstep, so it can have w32, x11, and ns frames, all displayed > on the same screen. Both ns and x11 frames will have a `display' set to > the same value (typically ":0.0" or something along these lines), > whereas the w32 frames's display will be "" (or nil, or ...). > This discrepency doesn't seem good. > > So maybe we should just make w32 use display=":0.0". 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. > The current display should be obtained via (frame-parameter nil 'display). Yes. My doubt was whether "current display" makes as much sense for Windows frames as it does for X ones. But I don't want to insist; I'd be happy just by fixing some of the issues, one way or another. So, please answer these: - 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)? - Do I change term/w32-win.el to use ":0.0" as argument to `x-open-connection'? - 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.) - Do we want `make-frame-on-display' to accept a null DISPLAY (on every platform) to mean "create a frame on the current display"? Juanma