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

[Karoly Lorentey]

Karoly Lorentey wrote:
> David has spotted a real bug.  According to current design, the third
> parameter to getenv should specify a terminal (i.e., it should be a
> numerical terminal id or a sample frame on that terminal).  Both the doc
> string _and_ the implementation is wrong, but the callers are right.  I
> probably committed an out-of-sync env.el somehow.

No, my memory has failed me.  I had a patch implementing the above design, but
what we currently have in the tree is something more complex: environment
variables are neither frame-, nor terminal-local, but rather client-local.

The client-local environment list is shared between frames that were created in
the same Emacsclient session.  The environment list is stored in a single
frame's environment parameter; the other frames' environment is set to this
frame.  (See `frame-with-environment'.)  Frames not originating from an
emacsclient session get the environment of the Emacs process itself, by the same
mechanism. (Note that when the user exits emacsclient, all frames belonging to
that client are automatically deleted.)

`process-environment' is nil by default.  If it is non-nil, its contents
override all client-local environment lists.

Since there is no "global" environment, getenv reports the selected frame's
environment by default, possibly overridden by process-environment.  If a third
parameter is given, it ignores `process-environment' (this must be fixed) and
simply returns the specific local environment that the user asked for.

Setenv, on the other hand, changes process-environment by default, overriding
the environment on all frames at once.

This approach does work quite well in practice, but it is ugly to implement. I
am open to suggestions to replace it with something better.  (At the very least,
getenv should not ignore `process-environment' when given a specific frame.)

Please consider the following:

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

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

          This means that having a different set of variables from frame to
          frame does not normally seem inconsistent or unpredictable to the
          user.

        - Furthermore, to me it seems more consistent to have all
          environment variables be local than just a select few of them.

        - Client-local environments mean that two separate emacsclient 
instances          on
the same terminal can have different environments:

                $ FOO=23 emacsclient
                        (getenv "FOO") ==> 23
                C-z
                $ FOO=42 emacsclient            # Other frame is still alive,
                        (getenv "FOO") ==> 42   # with a value of 23.

          This is a corner case that deepens the illusion of emacsclient being
          a real standalone editor.  It is not an important feature, although it
          did often come useful for me, particularly with long emacsclient
          sessions for different tasks, but sharing a single X display.

          Terminal-local environments would less complete, but still good enough
          to be usable without many problems.

        - The behaviour of M-x shell and similar packages is mostly irrelevant
          here.  I used to have a hack in my .emacs to have
          M-x shell create a new instance on each terminal automatically, nicely
          hiding environment-related inconsistencies.  There is no reason not to
          have something like that supported as an option.

If you find client-local environments unacceptably ugly, I can update and submit
my patch for simple terminal-local environments.  The local environment then
becomes a simple terminal parameter, initialized when the terminal is created.
This is a much simpler solution that retains much of the feature set of the
current design.

For now, the branch uses the implementation described above. The bug David
Kastrup found is now fixed correctly in Arch, and should be synced to CVS 
soonish.

-- 
Karoly