Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!necntc!ames!ucbcad!ucbvax!LF-SERVER-2.BBN.COM!jr
From: jr@LF-SERVER-2.BBN.COM (John Robinson)
Newsgroups: comp.emacs
Subject: Re: termcap capabilities used by Emacs
Message-ID: <8710022017.AA20437@ucbvax.Berkeley.EDU>
Date: Fri, 2-Oct-87 16:17:32 EDT
Article-I.D.: ucbvax.8710022017.AA20437
Posted: Fri Oct  2 16:17:32 1987
Date-Received: Tue, 6-Oct-87 05:44:52 EDT
References: <21074@ucbvax.BERKELEY.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: jr@ALEXANDER.BBN.COM
Distribution: world
Organization: The ARPA Internet
Lines: 20

>   Along the same lines, I understand that X-Windows will soon be
> available on Macintosh sized machines, and people are writing code to
> run it over serial lines (and therefore modems), are there any plans
> to write an Emacs client which can take advantage of local
> storage/processing speed? This could prove to make a dramatic
> difference in how effectively people can work remotely.

Emacs' current X support assumes a pretty fast medium between client
and server, so it would have to be taught a lot to do this right.  You
might be better off using kermit or equivalent (with suitable
compression) to transfer a file to the Mac, then edit it with Mac
microemacs, which is pretty respectable and certainly takes advantage
of the local processing capacity.  This approach may be a little
limiting without reasonable rotating storage (i.e. hard disk).  With
multi-finder, you could overlap kermit's work (which shouldn't consume
very much CPU at 1200 baud) with emacs's.  I expect this would perhaps
give you the optimum performance.

/jr
jr@bbn.com or jr@bbn.uucp