Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpfcso!hpfelg!koren From: koren@hpfelg.HP.COM (Steve Koren) Newsgroups: comp.sys.amiga Subject: Re: any luck with gnu-emacs? Message-ID: <13910044@hpfelg.HP.COM> Date: 3 Sep 90 00:51:26 GMT References: <14764@wpi.wpi.edu> Organization: HP Elec. Design Div. -FtCollins Lines: 175 > Has anyone had any luck with the gnu-emacs on abcfd20? Here is a little review of it that I wrote after playing with it. - steve ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Some thoughts on Amiga GNU Emacs V 0.1 -------------------------------------- Overall, general comment: This is the real thing folks!!!! I obtained the Amiga GNU Emacs port last night. I don't have any affiliation with the folks who are working on it; I have just wanted GNU emacs very badly on the Amiga. There are a few things you have to know to run it which aren't described in the distribution info file: * You have to set the Manx style environment variable TERM to be something which you will have in a termcap file. You can use the arp "set" command to do this. It won't see an AmigaDos ENV: variable of the same name. * You have to have a termcap file in s:termcap with a reasonable entry in it. vt100 almost works, but not quite. I used the Amiga termcap entry by Kent Polk with excellent results. It is short enough to include here for those who don't have it: # Amiga termcap by Kent Polk AA|amiga|Amiga ANSI:\ :co#80:li#24:am:bs:bw:\ :AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:\ :LE=\E[%dD:RI=\E[%dC:SF=\E[%dS:SR=\E[%dT:UP=\E[%dA:\ :ae=\017:al=\E[L:as=\016:bl=\007:bt=\E[Z:cd=\E[J:ce=\E[K:cl=\E[H\E[J:\ :cm=\E[%i%d;%dH:dc=\E[P:dl=\E[M:do=\E[B:ho=\E[H:ic=\E[@:is=\E[20l:\ :k1=\E0~:k2=\E1~:k3=\E2~:k4=\E3~:k5=\E4~:k6=\E5~:k7=\E6~:k8=\E7~:k9=\E8~:\ :k0=\E9~:kb=^H:kd=\EB:kl=\ED:kr=\EC:ku=\EA:le=\E[D:\ :mb=\E[7;2m:md=\E[1m:me=\E[0m:mh=\E[2m:mk=\E[8m:mr=\E[7m:nd=\E[C:nl=\E[B:\ :rs=\Ec:se=\E[0m:sf=\E[S:so=\E[7m:sr=\E[T:ue=\E[0m:up=\E[A:us=\E[4m:\ :ve=\E[\040p:vi=\E[\060\040p:xn: That should enable you to get emacs running. If you run it with the -lace option, you will have to change the number of lines entry in the termcap file, as it won't automatically detect that. I use 49 (ie, 50 minus one for the title bar). SIZE The emacs binary is huge - over 500K. You probably need at least a 2 meg system to run it and still have any memory left for other things. 3 or more would be preferable. It runs in its own custom screen. For the most part it doesn't take much stack. However, if you use (byte-compile-file), it will take a lot of stack - best to have 25K or more of stack. Otherwise, it seems to run OK in 6K to 10K of stack. SPEED It is surprisingly fast for a 68000. Faster than I expected for most things. It takes a *long* time to fire up, but the typing speed can keep up with my key repeat speed (pretty fast) with no problems. Things like line deletion and insertion, splitting windows, etc, are done intelligently and quickly (apparently though a curses library of some sort). The one thing that bothered me was moving to next or previous lines; it doesn't seem able to keep up with the key repeat speed. I'm sure it could on an '020 or faster. I've seen emacs perform worse on 68020 based Un*x machines due to intense swapping. The lisp interpreter seems tolerably fast as well. The only big problem at this point is that emacs busy-waits. You have to run it with a lower priority than other interactive things. This really needs to be fixed, IHMO. There is a noticeable delay (of about 1 second) when completing function names (of which there are several hundred, if not thousand). This is just running up against the horsepower limits of the 68000; with an '020 or '030 this problem should be eliminated. Its not even bad as it is now. In summary, it is usable on a 68000, but would certainly be more comfortable on a '020 or '030. COMPATIBILITY I was *very* pleasantly surprised, especially as this is early pre-release (0.1) code. Being one who writes software on Un*x for a living, I have developed a number of specialized lisp libraries to deal with C code. Some of these are pretty complicated, but ALL of them worked exactly as expected with no changes necessary. I also have tried other lisp libraries which were not included with the Amiga version. I tested these lisp libraries briefly; all seem to work fine: tags.el (Love it!!! I can't live without this anymore. The Amiga version didn't come with the etags program, so I brought the source (etags.c) over and compiled under Lattice, which worked with no problems at all). outline.el (does some fancy stuff hiding parts of buffers; works OK) rect.el (rectangular cut/past/insert/etc - works fine) calendar.el (simple - displays a calendar in a window) isearch.el (as fast as can be expected with a 68000 - as fast as the micro-emacses which do isearch). Seems like most "normal" lisp code will run just fine. However, a few of the more system dependent functions, such as (start-process), etc., don't work. This stops ispell.el and some other things from working. Also stops (shell-command), (compile), and friends from doing anything. Some other things which worked OK: recursive edits work split-window-horizontally works aprppos works byte-compile-file works c-mode works text-mode and auto-fill work multiple-level undo works eval-region works minibuffer-history works info works, provided you get the info files Only a limited number of lisp libraries come with it, but if you pull the others from a real GNU emacs, they will generally work. The release note claimed that file completion from the minibuffer was broken, but it seemed to be working most of the time for me. It correctly listed possible completions in another window, and , , and performed as expected. They also worked for buffer names, function names, etc. The alternate key works fine as a "meta" key. All keymaping stuff that I tried works. It doesn't currently load .emacs, but you can hack up the "loadup.el" file (or whatever its called) to make it load a .emacs. I didn't look in detail at memory allocation, but it did seem to free memory used by a buffer as soon as I killed the buffer. A few things are flakey at times: for example, if wanting a directory, you often MUST type the trailing slash ("/") for it to recognize that name as a legal directory. Also, trying to load a file from a directory other than the one you're cd'ed to will crash the machine most of the time. WHAT IT NEEDS: * single biggest thing: needs to avoid busy-waiting * some Amiga specific functions to set colors, fonts, etc * to get smaller, and maybe take advantage of some amiga specific routines which save space. * to get the rest of the functions (such as (start-process)) working * to be shipped with more of the standard lisp files, and info files * mouse support of some type, preferably similar to that in X11 emacs. COMMENTS: Its great! It is a little unstable at this point; I had it crash on me once for an unexplained reason. But it promises to provide a full blown GNU emacs for the Amiga, something we've never had before. The people who are doing the Amiga version seem to be doing a great job. If you have a small system or don't care about the full GNU functionality, you will probably want to use "mg" or another one of the good but small emacs-like editors if your want emacs. But if you have the space and the desire have the entire functionality of a full emacs, this is it. Many things I have, such as comedit.el, would be impossible to do with an ARP port into another editor; now I can at last have those things available both on my workstation at work and my Amiga at home. - steve (koren@hpfela.HP.COM) PS - this wouldn't even be runnable under MS-DOS with a 640K address space, as the binary is over 500K!