From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Evil Boris Newsgroups: gmane.emacs.devel Subject: Re: emacsclient's option decoding code Date: Fri, 14 Nov 2008 21:58:37 -0500 Message-ID: <33470.1440566734$1226718018@news.gmane.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1226717949 30786 80.91.229.12 (15 Nov 2008 02:59:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Nov 2008 02:59:09 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 15 04:00:10 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 1L1BOK-0005s2-2d for ged-emacs-devel@m.gmane.org; Sat, 15 Nov 2008 04:00:08 +0100 Original-Received: from localhost ([127.0.0.1]:47248 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L1BNB-0002qA-W0 for ged-emacs-devel@m.gmane.org; Fri, 14 Nov 2008 21:58:58 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L1BN6-0002pv-UN for emacs-devel@gnu.org; Fri, 14 Nov 2008 21:58:52 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L1BN5-0002pj-Dn for emacs-devel@gnu.org; Fri, 14 Nov 2008 21:58:51 -0500 Original-Received: from [199.232.76.173] (port=33372 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L1BN5-0002pg-8H for emacs-devel@gnu.org; Fri, 14 Nov 2008 21:58:51 -0500 Original-Received: from main.gmane.org ([80.91.229.2]:41178 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L1BN4-0008L1-Lf for emacs-devel@gnu.org; Fri, 14 Nov 2008 21:58:50 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L1BMz-0000p8-HQ for emacs-devel@gnu.org; Sat, 15 Nov 2008 02:58:45 +0000 Original-Received: from 207-38-194-119.c3-0.wsd-ubr5.qens-wsd.ny.cable.rcn.com ([207.38.194.119]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Nov 2008 02:58:45 +0000 Original-Received: from evilborisnet by 207-38-194-119.c3-0.wsd-ubr5.qens-wsd.ny.cable.rcn.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Nov 2008 02:58:45 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 21 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 207-38-194-119.c3-0.wsd-ubr5.qens-wsd.ny.cable.rcn.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (windows-nt) Cancel-Lock: sha1:Y3QC9QNfjMHz0sIgcwdrutvlbnM= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:105695 Archived-At: "Juanma Barranquero" writes: > IMO making a frame in the current display and making a frame in a > remote display are different operations and the point of call should > know about it. We don't usually conflate making tty and X frames, > either. I have been watching the arguments fly by and want to point out that, at least on X, IMHO, one cannot tell which X frames are local and which are not, for example, due to X tunnelling. So I am not convinced that either the client or the server can determine what to do if the precise recipe requested by the user fails/is unavaible. If the commands are used interactively, I would lean towards having them fail with an error, rather than try a default behavior that may or may not make sense. My concern however is that sometimes emacsclient is invoked as the editor in mail client, or in reverse search in a TeX previewer, or as an editor for log msgs in SVN etc. It is unclear to me what the right behavior is there---opening a frame in an inaccessible place seems like potential trouble. --Boris