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: Tue, 11 Nov 2008 10:39:28 +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 1226396391 17679 80.91.229.12 (11 Nov 2008 09:39:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Nov 2008 09:39:51 +0000 (UTC) Cc: cyd@stupidchicken.com, emacs-devel@gnu.org To: "Eli Zaretskii" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 11 10:40:52 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 1Kzpjv-00055M-9N for ged-emacs-devel@m.gmane.org; Tue, 11 Nov 2008 10:40:51 +0100 Original-Received: from localhost ([127.0.0.1]:47122 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kzpin-0008KG-DP for ged-emacs-devel@m.gmane.org; Tue, 11 Nov 2008 04:39:41 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kzpid-0008K1-F0 for emacs-devel@gnu.org; Tue, 11 Nov 2008 04:39:31 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kzpib-0008Jl-Ks for emacs-devel@gnu.org; Tue, 11 Nov 2008 04:39:30 -0500 Original-Received: from [199.232.76.173] (port=41795 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kzpib-0008Jb-Cm for emacs-devel@gnu.org; Tue, 11 Nov 2008 04:39:29 -0500 Original-Received: from an-out-0708.google.com ([209.85.132.246]:65289) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kzpia-00024c-V2 for emacs-devel@gnu.org; Tue, 11 Nov 2008 04:39:29 -0500 Original-Received: by an-out-0708.google.com with SMTP id c38so541793ana.21 for ; Tue, 11 Nov 2008 01:39:28 -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=yKzSoBHGy3Nt9qTUS7q7kW+sHuQO0OunIYXYVDohx+c=; b=tA5CYMtFNvKWZ87U/CB2HvftBP1MIwiHc4bMyy9/wr8RFflA3LkEgm6u4OYbRQ56lM ihbku+fFmiaLIa6/3iqbZf3DdDIeZLCqRrYKysvcL9aN2PHgop3oY636GVQ079EAgJ8x B0tblaLEdjpwgMgaY/alZq4iFLU/eOGR+6NDQ= 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=x1W7H+UVn473kQKi9tkg4Zr2Kp2OgQkDlrzZ4XGNGY5Wg3dYqYxvUV/k27URwUTaso y6ZEGXKUgyalsJygZ8+8grn2JFpUA+79Fh1ALjUtw4/U6hlZNc7dJYsPy+7oRf3g/AzR v3m805h98QQYyofvZE5N/3BWVrL6eO3HNRKj0= Original-Received: by 10.100.165.13 with SMTP id n13mr2736764ane.113.1226396368381; Tue, 11 Nov 2008 01:39:28 -0800 (PST) Original-Received: by 10.100.13.13 with HTTP; Tue, 11 Nov 2008 01:39:28 -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:105558 Archived-At: On Tue, Nov 11, 2008 at 05:09, Eli Zaretskii wrote: >> - emacsclient -c causes the same error, because emacsclient thinks >> that "-c" + null DISPLAY => "-t"; I proposed the attached patch (1), >> because even if -t is supported on Windows, the assumption that an >> empty DISPLAY implies a tty frame is false. > > Then why is the patch Windows-specific? If the above assumption is > false, it shouldn't be made on Posix platforms as well. > > Can someone explain why this assumption is in the code? Chong has already explained the assumption. And IMO that assumption is correct for POSIX, but will never (for some values of "never", of course) be for the Windows port, because even if we someday support X, Windows and tty frames simultaneously in the same running Emacs instance, it is a long shot to assume that any specific user will be using X or have DISPLAY defined in their environment. On POSIX, having DISPLAY defined is the norm; on Windows it will always be the exception, unless things change drastically. -c for a Windows user is much more likely to mean "another frame on my display" than "another frame on some remote X display", and if it really is the latter, well, then the probability of the user having DISPLAY set is much higher in the first place. (Note, BTW, that emacsclient's help for -c talks just about "a new frame", with no mention of DISPLAY.) > What happens if emacsclient is invoked with --display=DISPLAY argument > on Windows, after your patch? -d/--display is not currently accepted on Windows. Once activated, and without X display support: - As it stands now, with Chong's patch, if would make a frame on the current display. - With my patch, it would throw the "Invalid display, no HOST:SERVER or HOST:SERVER.SCREEN" error. I think the behavior I propose is more consistent. Also, if we someday implement X support on the Windows port, my patch would naturally work, while the current one would have to be fixed. IMHO the desire to fix the -c/-t problem on Windows has muddled the waters a bit. As I said in a previous message, if we want `make-frame-on-display' to allow `nil' to default to the current frame, that seems sensible. But making an exception for Windows and allowing "", or in fact any other value, string or otherwise, is ugly and just a consequence of the fact that (frame-parameter nil 'display) returns "" on Windows. The right thing to do IMHO is fix the places where the Windows port calls make-frame-on-display, and make sure that it passes nil when it really means "I don't have a DISPLAY". > Please add an entry to NEWS, so we won't forget that. I'll do as soon as we settle on a fix. Thanks, Juanma