Stefan Monnier wrote:
>> 	- At least some environment variables _must_ behave locally; if not
>> 	  client-locally, then at least terminal-locally.  DISPLAY is perhaps
>> 	  the most obvious example.  X clients such as xdvi started from Emacs
>> 	  must appear on the display the user currently works on.
> 
> Actually, the DISPLAY environment should behave that way even without the
> use of emacsclient (when you use make-frame-on-display).

Hm, this is a good point.

>> 	  This is an important feature for multi-tty users and I would like
>> 	  to keep it supported.  Similar variables include SSH_AUTH_SOCK,
>> 	  GPG_AGENT_INFO, AGENT_SOCKET, LANG, LC_*, and basically anything
>> 	  that may be different from login session to login session.
> 
> I don't think the vars you list are particularly important.  Which version
> of those vars to use (the one from the emacsclient process or from the main
> Emacs process) may depend from case to case.  So either choice is
> probably OK.

Well, I do agree that having a local DISPLAY is the essential feature here.

> I tend to think of emacsclient as "connect to the main Emacs process", so
> I tend to expect it to work in the environment of the main Emacs process.
> You seem to think of it as "pretend you're a normal Emacs process, just
> quick-started", so you expect a slightly different behavior.

The new emacsclient behaviour does make it easy to forget that you are
connecting to a separate Emacs process that runs in the background,
particularly when the main Emacs is not visible.  But I feel both
viewpoints can be catered for; "emacsclient --current-frame" reverts to
Emacs 22 behaviour, and should not touch the environment.

>> 	- Furthermore, to me it seems more consistent to have all
>> 	  environment variables be local than just a select few of them.
> 
> I don't find it important, but it doesn't seem to be bad either.  So I'd
> leave it as a choice that can be determined by the implementation.

OK.

-- 
Károly