spirkov@ernie.Berkeley.EDU.UUCP (10/02/87)
What termcap capabilities does Emacs (specifically GNU) actually use? I am planning to write a terminal editor for my Macintosh, since I haven't found anything usable that's already written, and I would like to make it as sophisticated as possible (I run at 1200 baud). What terminals out there are most sophisticated, and which capabilities are most critical to implement for speed in Emacs? Does Emacs manage to make use of any of the terminals which support more character memory than they can display on the screen? I.e., can Emacs down-load pages you haven't scrolled to yet, or at least scroll back to ones you've already seen without re-transmitting them? This could be particularly important for terminal emulators with access to large amounts of local memory. 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. I'll summarize responses if there are goodies... Matthew Self self@pluto.arc.nasa.gov (self@ames-pluto.arpa)
jr@LF-SERVER-2.BBN.COM (John Robinson) (10/02/87)
> 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