pawn@wpi.wpi.edu (Kevin Goroway) (08/30/90)
Has anyone had any luck with the gnu-emacs on abcfd20? Even the gnu-lisp file doesn't unarchive correctly... A full blown gnu-emacs port would be a wonderful thing. -- +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= | Worcester Polytechnic Institute | "It happens sometimes, people just | | Pawn@wpi.wpi.edu Pawn@wpi.bitnet | explode, natural causes."-Repo Man | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
bmacintyre@watcgl.uwaterloo.ca (Blair MacIntyre) (08/31/90)
>>>>> On 30 Aug 90 01:48:29 GMT, pawn@wpi.wpi.edu (Kevin Goroway) said:
Kevin> Has anyone had any luck with the gnu-emacs on abcfd20?
Kevin> Even the gnu-lisp file doesn't unarchive correctly...
Kevin> A full blown gnu-emacs port would be a wonderful thing.
The files were probably archived with an old 0.03 lharc. I got the
source to Unix lharc 1.0 and managed to hack it (using dbx and setting
the occasional variable to a more "appropriate" value :-) to extract the
files. Alas, the documention, when followed, is insufficient. I
couldn't get it running. It complained
"Please set the environment variable TERM; set tset(1)."
which (according to mail from the author) is telling me to set the amiga
env:TERM variable and put the supplied termcap in s:
Did this and it didn't work.
Don't bother downloading until this is cleared up. If I ever get it
working, I'll post what I know or get the author to do that.
--
-- Blair MacIntyre, Professional Leech on Society ( aka CS Graduate Student )
-- bmacintyre@{watcgl, violet}.{waterloo.edu, UWaterloo.ca}johnf@sag4.ssl.berkeley.edu (John Flanagan) (08/31/90)
In article <14764@wpi.wpi.edu> pawn@wpi.wpi.edu (Kevin Goroway) writes: >Has anyone had any luck with the gnu-emacs on abcfd20? >Even the gnu-lisp file doesn't unarchive correctly... >A full blown gnu-emacs port would be a wonderful thing. Use lharc 1.0 on a Unix system. It does work, but it uses termcap to get your terminal's characteristics (just like unix emacs), so you have to do a couple of special things. One is to put a "termcap" file in your s: directory, with one of the Amiga termcap definitions in it that are floating around for use with dnet. The other thing you need to do is set the environment variable TERM to "amiga" (or whatever you call your terminal definition in the termcap file). Unfortunately, this emacs does not use standard ENV: variables, but seems to use the Manx variety. This is annoying, but can be worked around if you use the ARP shell -- just type "set TERM=amiga." It is thrilling to see full-blown emacs running on the Amiga, but since it is still beta and missing a lot of features, it is not yet really any more useful than mg3beta4 (and somewhat less so if you really value ARexx ports). For one thing, it always opens a 23-line window, regardless of what is set in the termcap entry. For another, it always opens a separate window; if it is going to use termcap, it would be nice if it could have the option to run in the shell window from which it was called, thus opening up the way to use it over AUX:. More seriously for me, since it does not yet have shell hooks, you cannot do 'M-x shell' or 'M-x compile.' On the bright side, it does have the kill ring (for recursive undo), rectangle operations, and the other basic features which set it apart from mg. I look forward to the planned improvements listed in the doc file, and appreciate the effort being put into the port. This is going to be one great editing environment to have at home. --John John Flanagan Center for EUV Astrophysics johnf@ssl.berkeley.edu University of California (...!ucbvax!soc1.ssl!johnf) Berkeley, CA 94720 Manners Maketh Man. (415) 643-6308
koren@hpfelg.HP.COM (Steve Koren) (09/03/90)
> 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 <spc>,
<tab>, and <nl> 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!drw900@anusf.anu.edu.au ("Drew R Whitehouse") (09/04/90)
In article <13910044@hpfelg.HP.COM>, koren@hpfelg.HP.COM (Steve Koren) writes: |> > Has anyone had any luck with the gnu-emacs on abcfd20? |> |> COMMENTS: |> |> Its great! Ditto !!!, just one thing though, it would be nice if it worked to the full PAL resolution for those of us lucky ?? enough to have more lines on our screens. Keep up the good work ! --------------------------------------------------------------------------*/ /* Drew Whitehouse, E-mail: drw900@anusf.anu.edu.au */ /* Visualization Programmer, Fax : (06) 2473425 */ /* Australian National University, Phone : (06) 2495985 */ /* Supercomputer Facility. */ /* GPO Box 4, Canberra ACT Australia 2601. */ /*---------------------------------------------------------------------------*/
ath@lcs.mit.edu (Andrew Heybey) (09/04/90)
In article <1990Sep4.152706@anusf.anu.edu.au> drw900@anusf.anu.edu.au ("Drew R Whitehouse") writes: |> Its great! Ditto !!!, just one thing though, it would be nice if it worked to the full PAL resolution for those of us lucky ?? enough to have more lines on our screens. Keep up the good work ! As a temporary kludge, you can use a binary editor to hack the window to be a different size. Look for hex digits 0280 00c8 in the binary. They appear twice, 32 bytes apart. These are the NewScreen and NewWindow structures. Worked for me (though I have only tried "temacs -nocustom", which opens a window on the workbench). andrew -- Andrew Heybey, ath@ptt.lcs.mit.edu, uunet!ptt.lcs.mit.edu!ath