I have updated my Emacs patches for multi-tty support.  The new
version has (I think) pretty reliable support for multiple tty
devices.  Plus, X support has been fixed, and now it is possible to
have simultaneous termcap and X frames (although this mode is still
somewhat unstable).

The attached patch should apply cleanly against any recent CVS HEAD.
Instructions for direct access to my arch branch and the latest
patches may be found at

	http://lorentey.web.elte.hu/project/emacs.html

There is a (silly) screenshot of a tty+X combo session at

	http://lorentey.web.elte.hu/images/emacs/multi-tty-screenshot.png

Please let me know what you think about this project.  I badly need
testers, so if you think this would be useful for you, please give it
a try and tell me your results.  (Note that Mac, MSDOS and Windows
support is broken at the moment, and I will probably need some help
with these ports later.)  Please read the README.multi-tty file for
compilation instructions and known issues.

The huge size of the patch is due to my converting of dozens of global
variables into frame-local or display-local parameters.  It was a
pretty straightforward job, but I had to change a lot of code, and I
had to made a few ,,design'' decisions.  Therefore, I would also like
comments and suggestions on the implementation from knowledgeable
Emacs hackers -- please rip my code apart and tell me how
ugly/inefficient/buggy it is.

My goal is of course to have my branch merged into CVS HEAD at some
point in the future.  Long ago, when I converted from XEmacs to Emacs,
this was the one feature that I sorely missed.

Some use cases:

  * Emacs is notoriously slow at startup, so most people use another
    editor or emacsclient for quick editing jobs from the console.
    Unfortunately, emacsclient was very awkward to use, because it did
    not support opening a new Emacs frame on the current virtual
    console.  Now, with multi-tty support, it can do that.  (Note that
    emacsclient starts up even faster than vi!)

  * Some Gnus users (including me) run Gnus in an X frame in its own
    Emacs instance, which they typically leave running for weeks.  It
    would be nice if they could connect to this instance from a remote
    ssh session and check their messages without opening a remote X
    frame or resorting to gnus-slave.