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

[David Kastrup]

Stefan Monnier <address@hidden> writes:

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

Agreed.  But terminal-locality is all that is required (and in my
opinion appropriate) here.  And it is _not_ a matter of "exporting"
the start _environment_, but rather of exporting the start _settings_.

I would argue that an Emacs started with
DISPLAY=:0.0 emacs -display :1.0
should export an environment variable DISPLAY=:1.0 to its subprocesses
unless explicitly overridden.  This is somewhat complicated by the
situation given with
DISPLAY=:0.0 emacs -nw
In this case, I would still want to export :0.0 to subprocesses, and
in the case
DISPLAY=:0.0 emacs -nw -display :1.0
I would suggest a non-graphical instance of Emacs exporting a DISPLAY
variable of :1.0.

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

Where Emacs' behavior depends on such variables, it might make sense
to let them influence Emacs' behavior in terminal-local entities, and
have a default export mechanism based on those terminal-local recorded
settings.  It would seem desirable to have parallel terminal sessions
from an iso-8859-1 terminal and a utf-8 terminal into Emacs possible
without getting garbled screens.  In particular the ability to edit
right-to-left languages in a terminal capable of RTL languages, while
keeping a non RTL-capable environment for other tasks, might be one
step in the course of getting Emacs usable in RTL environments.

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

And I don't think that Emacs can actually be even close to satisfying
the second paradigm, so there is little sense in doing a half-baked
version of it and failing.

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

I disagree.  If I have two frames side by side displaying the same
buffer, it will be extremely confusing if using setenv in one frame
will not have an effect on the other frame when calling commands with
M-!.

Any setenv on the same _terminal_ should certainly affect the
operation on the other end.  And I claim that for not display-related
environment variables like "PATH", the same should hold _across_
terminals.  terminal-specific variables like "DISPLAY" and possibly a
subset of LC* variables should, in contrast, usually be managed
terminal-locally.

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

Disagree.  It makes shell buffers behave totally unpredictable across
terminals (or even worse, frames): the sequence
exit RET M-x shell RET
usually gets rid of environment variables set within the shell
session.  It would not be nice to have to guess what behavior will
result.

AUCTeX, for example, contains code like the following:

(defun preview-set-texinputs (&optional remove)
  "Add `preview-TeX-style-dir' into `TEXINPUTS' variables.
With prefix argument REMOVE, remove it again."
  (interactive "P")
  (let ((case-fold-search nil)
        (preview-TeX-style-dir (preview-TeX-style-cooked))
        pattern)
    (if remove
        (progn
          (setq pattern (concat "\\`\\(TEXINPUTS[^=]*\\)=\\(.*\\)"
                                (regexp-quote preview-TeX-style-dir)))
          (dolist (env (copy-sequence process-environment))
            (if (string-match pattern env)
                (setenv (match-string 1 env)
                        (and (or (< (match-beginning 2) (match-end 2))
                                 (< (match-end 0) (length env)))
                             (concat (match-string 2 env)
                                     (substring env (match-end 0))))))))
      (setq pattern (regexp-quote preview-TeX-style-dir))
      (dolist (env (cons "TEXINPUTS=" (copy-sequence process-environment)))
        (if (string-match "\\`\\(TEXINPUTS[^=]*\\)=" env)
            (unless (string-match pattern env)
              (setenv (match-string 1 env)
                      (concat preview-TeX-style-dir
                              (substring env (match-end 0))))))))))

(defcustom preview-TeX-style-dir nil
  "This variable contains the location of uninstalled TeX styles.
If this is nil, the preview styles are considered to be part of
the installed TeX system.

Otherwise, it can either just specify an absolute directory, or
it can be a complete TEXINPUTS specification.  If it is the
latter, it has to be followed by the character with which
kpathsea separates path components, either `:' on Unix-like
systems, or `;' on Windows-like systems.  And it should be
preceded with .: or .; accordingly in order to have . first in
the search path.

The `TEXINPUT' environment type variables will get this prepended
at load time calling \\[preview-set-texinputs] to reflect this.
You can permanently install the style files using
\\[preview-install-styles].

Don't set this variable other than with customize so that its
changes get properly reflected in the environment."
  :group 'preview-latex
  :set (lambda (var value)
         (and (boundp var)
              (symbol-value var)
              (preview-set-texinputs t))
         (set var value)
         (and (symbol-value var)
              (preview-set-texinputs)))
  :type '(choice (const :tag "Installed" nil)
                 (string :tag "Style directory or TEXINPUTS path")))


It is a straightforward manipulation of process-environment intended
to work for the entire session, on variables that have nothing to do
with the DISPLAY.

We don't want to have _any_ such code just break.  It is _not_ code
that is written sloppily or making unfounded assumptions.  It needs to
access all environment variables obeying a given pattern and
manipulate them.  It does this by looping through process-environment
(more exactly, a copy of it so that the exact implementation of setenv
can't interfere with the loop).  This is completely straightforward,
not related to multi-tty-ness at all, and we don't want such usage to
break.

> So I'd leave it as a choice that can be determined by the
> implementation.

Guffah.  Uh, the implementation will, _of_ _course_, determine _every_
choice.  That's why we are discussing it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum