From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Change in emacsclient behavior Date: Fri, 31 Aug 2007 10:09:49 +0200 Message-ID: <86zm08gm5u.fsf@lola.quinscape.zz> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1188547851 30639 80.91.229.12 (31 Aug 2007 08:10:51 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 31 Aug 2007 08:10:51 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 31 10:10:48 2007 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 1IR1aV-0007bg-VG for ged-emacs-devel@m.gmane.org; Fri, 31 Aug 2007 10:10:44 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IR1aV-00069P-CO for ged-emacs-devel@m.gmane.org; Fri, 31 Aug 2007 04:10:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IR1Zg-0005kf-LD for emacs-devel@gnu.org; Fri, 31 Aug 2007 04:09:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IR1Zf-0005jt-Nj for emacs-devel@gnu.org; Fri, 31 Aug 2007 04:09:52 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IR1Zf-0005jf-2Y for emacs-devel@gnu.org; Fri, 31 Aug 2007 04:09:51 -0400 Original-Received: from pc3.berlin.powerweb.de ([62.67.228.11]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IR1Ze-0006pg-JI for emacs-devel@gnu.org; Fri, 31 Aug 2007 04:09:50 -0400 Original-Received: from quinscape.de (dslnet.212-29-44.ip210.dokom.de [212.29.44.210] (may be forged)) by pc3.berlin.powerweb.de (8.9.3p3/8.9.3) with ESMTP id KAA28844 for ; Fri, 31 Aug 2007 10:09:48 +0200 X-Delivered-To: Original-Received: (qmail 23160 invoked from network); 31 Aug 2007 08:09:49 -0000 Original-Received: from unknown (HELO lola.quinscape.zz) ([10.0.3.43]) (envelope-sender ) by ns.quinscape.de (qmail-ldap-1.03) with SMTP for ; 31 Aug 2007 08:09:49 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id 5A0978FA33; Fri, 31 Aug 2007 10:09:49 +0200 (CEST) In-Reply-To: (Stefan Monnier's message of "Fri\, 31 Aug 2007 02\:39\:08 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) X-Detected-Kernel: Linux 2.4-2.6 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:77467 Archived-At: Stefan Monnier writes: >> I think this change is a mistake: >> +** Emacsclient has been extended to support opening a new terminal >> +frame. Its behavior has been changed to open a new Emacs frame by >> +default. Use the -c option to get the old behavior of opening files in >> +the currently selected Emacs frame. > >> For people that normally don't make new frames, this will be a hassle. > > Agreed. It may also be a hassle for people who use multiple frames because > IIUC it will create only one frame per emacsclient rather than one per file, > like I use. > >> So I think it should depend on the value of `pop-up-frames'. > > I disagree. It should just revert to the old behavior (i.e. revert the > "-c" arg to emacsclient). > >> Are there any arguments against testing `pop-up-frames'? > > If I understand the code correctly, the choice is made in emacsclient, so it > does not have access to `pop-up-frames' anyway. Here is my take on that from looking over the old emacsclient code (so of course the take is out of date): It really does not make any sense to let emacsclient do the option parsing. It is much more flexible to let the server deal with that since we then have the full power of Elisp available and all information and variables we might want. So emacsclient should just parse those initial options it needs to contact Emacs, and then hand over the rest, and then set itself into a loop where it just does Emacs' bidding. This bidding could include - request particular environment variables (typically TERM and/or DISPLAY) - request a line from stdin (or specified file descriptor) - send data to stdout (or specified file descriptor) - request the tty name - for later: if the connection is non-local, tty control might be interesting: Emacs would then be talking to the terminal through Emacsclient as a proxy. - exit with given exit status Anything else is best dealt with on the Emacsserver side, I think. -- David Kastrup