jfjr@MITRE-BEDFORD.ARPA (Freedman) (04/15/88)
In the Encore promotional stuff they talk about a special editing protocol developed by RMS to allow some of GNU-emacs to reside on the ANNEX and some on the ENCORE. Does this come with the standard distribution? How do you turn it on if it does? Has anybody any experience with it? Jerry Freedman, Jr "Love is staying up all night jfjr@mitre-bedford.arpa with a sick child, (617)271-4563 or a healthy adult"
ford@kenobi.UUCP (Mike Ditto) (04/18/88)
Posting-Front-End: GNU Emacs 18.41.10 of Fri Oct 2 1987 on kenobi (usg-unix-v) In article <8804151243.AA03591@mitre-bedford.ARPA> jfjr@MITRE-BEDFORD.ARPA (Freedman) writes: > In the Encore promotional stuff they talk about a special editing > protocol developed by RMS to allow some of GNU-emacs to reside on the > ANNEX and some on the ENCORE. Does this come with the standard > distribution? How do you turn it on if it does? Has anybody any > experience with it? I've used it. It's called LEAP (Local Editing Acceleration Protocol?) and it uses a tcp connection to the Annex (Encore's intelligent terminal multiplexer). When Emacs starts up, it opens the connection to the annex and downloads the termcap entry and the current keymap. Then, whenever the user types a key that is bound to a function the Leap server "understands", the display is locally updated by the annex. When Leap doesn't understand a command, Emacs is notified of all the keystrokes that the server has already processed and of the new command yet to be performed. Emacs "catches up" by making any necessary changes to buffers, etc., and then executes the command that the Leap server couldn't deal with. Emacs assumes that the display already is up to date except for the last command and updates it accordingly, then lets the server take over again. The idea is to have simple things like self-insert-command and delete-backward-char handled by the Annex rather than require a whole context switch for emacs to read and echo each byte. Only a small number of commands need to be known by the Leap server to achieve a great performance improvement in terms of CPU time used during normal editing. When I was running Emacs on an Encore, the distribution we had included all the Leap stuff merged into Emacs. But I just checked the Emacs sources on my machine and the relevant files are not there. There should be a leap/ directory on the same level as src/ and, if I remember correctly, a lisp/leap.el and a src/leap.c. One disadvantage (of the version I was using) was that it had to use termcap (everything else on the system used terminfo.) This was because the Leap protocol requires downloading an actual termcap entry. There were a few bugs, but it was an early version. Basically, I used it for a while just to see if it worked, but since it didn't offer any functional advantages I stopped using it. We never really noticed any performance impact on the system anyway (those Multimaxes are fast, and there were just three of us using it). The protocol is documented, so theoretically, anyone could write a leap server. Also, it's actually a general editing protcol, so it would be just as happy accelerating vi as Emacs. Of course, vi is such a kludge to begin with it will probably never be modified in such a way. -=] Ford [=- "Once there were parking lots, (In Real Life: Mike Ditto) now it's a peaceful oasis. ford%kenobi@crash.CTS.COM This was a Pizza Hut, ...!sdcsvax!crash!kenobi!ford now it's all covered with daisies." -- Talking Heads
lyndon@ncc.UUCP (Lyndon Nerenberg) (04/19/88)
There is a version of gnuemacs included on the software distribution tape that comes with the Annex. It has been modified to use the LEAP protocol support in the terminal server. I haven't installed this version here as it is a bit out of date. Some day I might try isolating the code and updating a later version of emacs to use it... -- {alberta,telebit,utzoo,uunet}!ncc!lyndon lyndon@Nexus.CA