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

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

> particular regarding the exported value of DISPLAY to processes.  The
> situation is less clear about values like TERM: however, exporting
> them (or their equivalent) seems reasonable when we are talking about
> MSDOS where a started subprocess will run in the tty of the actual
> Emacs and talk to it bypassing Emacs' redirection stdout/stderr.

Actually, for a short time the CVS code scrapped the $TERM environment
variable, since the terminal is not accessible to Emacs's
subprocesses anyway.  The fundmental idea was agreed upoon, was the patch
was reverted because I didn't test it enough: the TERM var was scrapped too
early.  E.g. it was scrapped before it got a chance to be used to load the
term/$TERM.el file, and also before reading the user's .emacs file where
some users use $TERM for one reason or another.
In any case the conclusion was that the $TERM var should be scrapped
much later.  Probably by separating the "environment inherited" (where TERM
would be kept for the whole duration of the Emacs session) from the
"environment passed down to subprocesses".

I didn't know that the MS-DOS port does make Emacs's terminal available
directly to its subprocesses, but that can be easily accomodated.

This brings us back to multi-tty's handling of environments.  I think
breaking backward compatibility to some extent is unavoidable because there
needs to be several different notions of environments, such as the two
mentioned above.  I think it's a good opportunity to think hard about what
setenv/getenv/process-environment should really do and how to
extend/replace them.  Your message was a good start in that direction, but
I think we should first try to imagine "what should things be like,
regardless of backward compatibility" and only afterwards try to see how to
best map it to the old interface.


        Stefan