emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Change in emacsclient behavior


From: David Kastrup
Subject: Re: Change in emacsclient behavior
Date: Fri, 31 Aug 2007 10:09:49 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux)

Stefan Monnier <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]