RDROYA01@ULKYVX.BITNET (Robert Royar) (09/20/86)
I use uEmacs on the ST for everything (v3.7). I hacked on version 27 for a year with CP/M-68. And I use GNU_EMACS on a VAX. While the commands are similar between the two programs, GNU is chock-full-o usefull features that the current micro version just can't handle. But from looking at some of the GNU sources I would say "if you want to port it without Mock Lisp, forget it." Mock Lisp is an integral part of the package. In fact many of the mode specific and "extra" features of the GNU program seem to depend on Mock Lisp. I suggest if anyone wants GNU on an Atari, she check out the program carefully and the sources; then compare those to uEmacs and its sources with the goal of expanding the micro version to include some of the features. But just think how fast your disk space will dissappear with 100K info files lying around, and how will you handle all those real un*x functions that rely on concurrency? One idea I had, but which seems beyond me now, is to merge uEmacs with Xlisp. With a bit of tweeking, the Xlisp interpreter can be made to read and evaluate mock-lisp files. BTW a new version of GNU has been announced and might be out by the time you read this. Robert Royar rdroya01@ulkyvx.bitnet
phr@ernie.Berkeley.EDU (Paul Rubin) (09/21/86)
A few people have mentioned Mock Lisp in GNU Emacs. I'd like to correct this: Mock Lisp simple Lisp-like language used in Gosling Emacs which is now sold by Unipress Corp. It is called "Mock" Lisp because among other things it doesn't have a CONS function. GNU Emacs Lisp is a real Lisp (including CONS) which some pretty substantial programs have been written in. Most of GNU Emacs's editing commands are written in Lisp. In my opinion, trying to merge Xlisp with MicroEmacs would result in a horrible kludge and trying to make it able to run GNU Emacs Lisp functions would, if it is feasible at all, give you a program as big as GNU Emacs. It would be simpler to just port GNU Emacs to the ST. This is not a completely crazy thing to contemplate doing on a 1 megabyte machine and is a completely reasonable idea with 2 or 4 megabytes. (The program text segment of GNU Emacs is about 600k on a VAX, which includes a lot of sharable Lisp code as well as a lot of code for things like Unix asynchronous process control which would have to be flushed on an ST). Someone (Bradley Mitchell?) has made an extensible MicroEmacs by combining it with a FORTH system. That seems like a more sensible approach than writing a Lisp system if the goal is to keep the program small; however, writing very complicated macros is probably more difficult. I've never used FORTH so I don't know for sure.
preece@ccvaxa.UUCP (09/24/86)
People should realize that some of the nicest features of GNUemacs are things that would be lost in a port to the ST: compiling from inside an edit session, shell windows, and filtering regions through commands are obviously not going to work without Unix multitasking. It's still a nice editor, and without those features it might be small enough to fit... -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@gswd-vms
higgin@cbmvax.cbm.UUCP (Paul Higginbottom) (09/26/86)
In article <109200001@ccvaxa> preece@ccvaxa.UUCP writes: >People should realize that some of the nicest features of GNUemacs >are things that would be lost in a port to the ST: compiling from >inside an edit session, shell windows, and filtering regions >through commands are obviously not going to work without >Unix multitasking. It's still a nice editor, and without those >features it might be small enough to fit... > >-- >scott preece >gould/csd - urbana >uucp: ihnp4!uiucdcs!ccvaxa!preece >arpa: preece@gswd-vms I couldn't resist replying to this one. The ST computers are GREAT machines but they need a multi-tasking O/S SOOOOO badly. The features mentioned above would port fine to the Amiga. My uEmacs on the Amiga can spawn off shells, execute a make or a cc while I'm still editing, etc. That saves me TONS of time (forget it if you're using floppies - i.e., doing mulitple floppy operations, but with a hard disk... it's usable). The trouble is... if Atari chose UNIX (which I highly doubt they will) they'll have support nightmares, and the reason I highly doubt they will is that UNIX is HUGE. Sure you MIGHT get a kernel and a few bits and pieces to run on a 1040ST, but all the utilities? I remember laughing when I played with an ATT7300 (UNIX box) which had 4% available disk space upon powering up for the FIRST time! What use is that? PLEASE don't construe this message as another "this machine [AMIGA] is better than that machine [ST]", my point was that multi-tasking is incredibly useful, not only for developing, but for application users too, e.g: boot the word processor, then boot the spreadsheet as well! With inter-process communication, you can have real time integration. So what are the options for the ST? I read about O/S-9 - sounds good, but is it reliable, efficient, etc? Anyone know what Atari's plans might be? I mean TOS/GEM/etc doesn't cut the mustard right now I don't think. Fixed limits on accessed directories!?!!? Fixed #'s accessories and/or windows? Geeez... guess they use fixed arrays inside. Can you say "lists"? Paul. Disclaimer: I do not work for anyone, and my opinions are my own.
turner@imagen.UUCP (D'arc Angel) (09/29/86)
> Nf-ID: #R:<8609201259.AA04886@ucbvax.Berke:-40:ccvaxa:109200001:000:452 > Nf-From: ccvaxa.UUCP!preece Sep 24 09:47:00 1986 > > > People should realize that some of the nicest features of GNUemacs > are things that would be lost in a port to the ST: compiling from > inside an edit session, shell windows, and filtering regions > through commands are obviously not going to work without > Unix multitasking. It's still a nice editor, and without those > features it might be small enough to fit... > > -- > scott preece > gould/csd - urbana > uucp: ihnp4!uiucdcs!ccvaxa!preece > arpa: preece@gswd-vms wanna bet ??? i can compile, run commands, etc. from within uE3.7i; but i will admit that porting GNUemacs would be a mistake -- ---- It aint life that gets me down, it's gravity Name: James M. Turner Mail: Imagen Corp. 2650 San Tomas Expressway, P.O. Box 58101 Santa Clara, CA 95052-8101 AT&T: (408) 986-9400 UUCP: ...{decvax,ucbvax}!decwrl!imagen!turner CompuServe: 76327,1575 GEnie : D-ARCANGEL
tim@ism780c.UUCP (Tim Smith) (10/04/86)
In article <109200001@ccvaxa> preece@ccvaxa.UUCP writes: > > People should realize that some of the nicest features of GNUemacs > are things that would be lost in a port to the ST: compiling from > inside an edit session, shell windows, and filtering regions > through commands are obviously not going to work without > Unix multitasking. It's still a nice editor, and without those > features it might be small enough to fit... > Why do you need multitasking to filter a region through a command? As long as the system provides a way to specify what program to use as a shell you should be able to do filters. -- member, all HASA divisions POELOD ECBOMB -------------- ^-- Secret Satanic Message Tim Smith USENET: sdcrdcf!ism780c!tim Compuserve: 72257,3706 Delphi or GEnie: mnementh