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

[David Kastrup <dak@gnu.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

I don't know about the port actually, and it is not a matter of making
the terminal available as much as the subprocess just taking it, I
think.  The screen memory is there, and the BIOS routine accessing it
are there.  How is Emacs going to keep a subprocess from using those?

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

To some extent, yes.  I am fine with breaking previous
terminal-related code as much as required.  I am less fine with
breaking anything environment-related.

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

For everything that is not terminal-related, nothing but a single
environment makes sense, I think: basically all code manipulating
environments assumes this, and there is quite a bit of code that might
not even get run in a terminal.

Anyway, when we split environments in _any_ way, it means that
processes will have to keep an idea of what terminal they belong to so
that this terminal can be reselected in their process sentinels and
filter functions: it is important that the process sentinel can rely
on having the same environment variables for further processes started
from there.

Maybe this already is implemented, and maybe even in trunk: no idea.

Also the environment situation seems to be ugly with regard to code
being run from timers: maybe one should refrain from starting
terminal-dependent processes from timers.  Not being allowed to start
any processes seems like overkill, but we can't rely on the
terminal-related parts of it to stay around, can we?

-- 
David Kastrup