Eli Zaretskii wrote:
>> One thing that I personally am concerned about is that it might be
>> difficult to reach a consensus about what kind of environment model we
>> should be using and documenting.  There have not actually been many
>> people involved in the discussion, but it is clear that there are
>> quite different standpoints from the user experience and the system
>> architecture point of view.
> 
> One reason why _I_ wasn't part of the discussion is that I couldn't
> find any place where the design principles of multi-tty are described
> in sufficient detail for me to make up my mind about it.  Is there
> such a document out there?  If not, could someone ``in the know'',
> preferably Karoly himself, please describe the feature and its main
> design principles?

In terms of core Emacs features, the multi-tty branch adds the
capability to create frames on multiple tty devices at once (hence the
name).  It also adds support to simultaneously have X and tty frames in
the same Emacs session.

The tty support is such that different terminals may have different TERM
settings, character encodings, color depths and function key maps
applied to them.

X support is basically similar to what we have in the trunk; i.e., Emacs
can open frames on multiple X servers at once, and this works pretty
reliably.  One area of difference is that on the multi-tty branch, an X
server problem (such as an X server crash) will not necessarily bring
down the entire Emacs process: it will simply delete the broken
terminal. If other terminals remain, then Emacs will continue to work
after such a disconnect.

The original goal of the multi-tty project was to improve how
emacsclient works: I always felt it should open a new frame on
emacsclient's terminal by default.  This wasn't possible before when X
was not available on the emacsclient side, but in this case now Emacs
can simply open a frame on the local tty device.  Some things that
deserve mention about the new Emacsclient:

   1. Emacsclient opens a new frame by default.  It prefers X, but
      falls back to tty when necessary or when forced, just like Emacs
      itself.

   2. Frames are associated with the emacsclient session they were
      created in.  C-x 5 2 makes the new frame inherit the association
      as well.  When the user closes the last frame associated with a
      particular emacsclient session, emacsclient exits automatically,
      and vice versa.  C-x C-c is rebound to exit the client, not Emacs
      itself.

   3. When there is a tty frame open on emacsclient's controlling tty,
      you can send emacsclient into the background by pressing C-z.
      Emacs then suspends input/output to the tty device, and the
      emacsclient process stops itself, returning you to the shell
      prompt.   This works just like any standalone UNIX application
      would.  As a little no-cost extra feature, you can even create
      multiple emacsclient sessions running at the same time on the same
      terminal, and transparently switch between them by C-z and fg.

      More on the tty suspend feature: tty terminals can be suspended
      and resumed from Elisp.  Output is never sent to and input is
      never read from suspended terminals, but otherwise they keep their
      set of frames and windows configurations.  To resume output,
      suspended terminals must be explicitly resumed by another elisp
      call.  (This was something like a low-cost bonus feature that
      was very little work to implement, but considerably improves user
      experience.)

   4. Environment variable handling is currently in a state of flux;
      see the separate thread for that.

I think the best way to get a handle on the multi-tty branch is to
compile it and try out the new emacsclient.  It should be a convincing
emulation of a superfast little standalone editor, but with Emacs's
power, and built-in sharing of state between session.  Achieving this
was my primary goal, and I like how the results turned out very much.

-- 
Karoly