Re: Multi-tty design (Re: Reordering etc/NEWS)

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 	- 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).

> 	  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.

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.

> 	- For the user, there is a strong sense of connection between
> 	  an emacsclient instance and its set of frames.  If emacsclient
> 	  exits, then its frames are deleted and vice versa.  C-x C-c kills
> 	  emacsclient, not the entire Emacs process.  All this feels
> 	  very natural and fits a range of common use-cases, particularly
> 	  the ones involving quick editing jobs from the command prompt.
> 	  (These are the ones for which Emacs was so infamously not well
> 	  suited before.)

Yes, it's probably OK to use frames as an approximation of "terminal" or
"display" or "client".

> 	- 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.


        Stefan