From xemacs-m  Thu Mar 27 11:23:55 1997
Received: from mail.cis.ohio-state.edu (mail.cis.ohio-state.edu [164.107.8.55])
	by xemacs.org (8.8.5/8.8.5) with SMTP id LAA18569
	for <xemacs-beta@xemacs.org>; Thu, 27 Mar 1997 11:23:55 -0600 (CST)
Received: from calico.cis.ohio-state.edu (calico.cis.ohio-state.edu [164.107.142.11]) by mail.cis.ohio-state.edu (8.6.7/8.6.4) with ESMTP id MAA01923; Thu, 27 Mar 1997 12:23:43 -0500
Received: (ware@localhost) by calico.cis.ohio-state.edu (8.8.0/8.6.4) id MAA07410; Thu, 27 Mar 1997 12:23:42 -0500 (EST)
To: xemacs-beta@xemacs.org
Subject: Future ideas
From: Pete Ware <ware@cis.ohio-state.edu>
Date: 27 Mar 1997 12:23:40 -0500
Message-ID: <vwm9139z1sz.fsf@calico.cis.ohio-state.edu>
Lines: 20
X-Mailer: Gnus v5.4.36/XEmacs 19.15(beta104)

Hmm, I just saw Jamie Zawinski post a request to comp.emacs.xemacs
about remote gdb.  It triggered an idea.

1. I've been using/hating gnuattach intermittently.  My first thought
   was why does XEmacs need direct control of the tty?  What about
   just transmitting all the input/output through a socket?  That way
   gnuattach can deal with keyboard signals appropriately and it can
   be used on remote machines.

2. How about allowing a process server to be associated with a device
   and/or buffer?  When processes are started under XEmacs, instead of
   just fork/exec it sends a request to the frame or buffer's process
   server which may be on a remote machine.  As with gnuattach, all
   input/output is served through a socket.  The remote server can
   manage the pty's (as appropriate).

   Combined with efs, I can now edit/compile/debug/latex/shell on a
   remote machine.

--pete

