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

[Eli Zaretskii]

> From: David Kastrup <address@hidden>
> Date: Fri, 18 May 2007 09:36:48 +0200
> Cc: Andreas Schwab <address@hidden>, Dan Nicolaescu <address@hidden>,
>       Karoly Lorentey <address@hidden>, address@hidden, address@hidden
> 
> Stefan Monnier <address@hidden> writes:
> 
> > > I think that "client-local" is a complication we really don't want to
> > > introduce.  It is clear that frames on different servers or ttys will
> > > have to have different personalities regarding the terminal, and in
> > > 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.
> > 
> > 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?

I didn't track this thread, so apologies if I will talk nonsense.

In a nutshell, I don't see how any of this is a concern in the MSDOS
port.

First, the MSDOS port does not support (and cannot support) multiple
displays, it only supports a single display: the local text terminal.
So the multi-tty features will at most be a no-op on MSDOS.

Second, $TERM is not used on MSDOS: there's no notion of different
terminal drivers for different types of terminal; all DOS-compatible
terminals support a single set of feature that cannot be modified, not
by termcap style config file, anyway.  (You will see in the Emacs code
that the MSDOS port sets TERM to a special value "internal", to signal
to term.c and its ilk that the internal emulation of a terminal is
used, and also to make use of the normal Emacs mechanism of loading
lisp/term/$(TERM) at startup.  But you cannot set TERM to anything
else and get useful results.)  So neither the MSDOS port nor any other
DOS programs it may run as subsidiary processes could ever care about
the value of TERM.

Third, the MSDOS port indeed does nothing to prevent a subprocess from
writing to the screen, but no program in its right mind should do that
when invoked with its stdout redirected to a file.  If there is a
program which does that, it is simply buggy.  Interactive programs
that need screen access should be invoked after shelling out of Emacs
(with C-x C-z); for this use case, Emacs on MSDOS saves the screen
contents before shelling out and restores it when the subsidiary shell
exits.

I hope these comments help.  Don't hesitate to ask questions if you
have any.