bmacinre@watcgl.uwaterloo.ca (Blair MacIntyre) (09/07/90)
Just a quick note:
The guy who is porting Gnu Emacs put up version 0.3 Beta, which corrects
a few very important problems:
- no more busy wait!
- uses Amiga ENV:TERM instead of Manx env variables.
So, if you want to play with it, it's almost usable now. Of course, the
thing still takes 3 minutes to load, so it's not for the casual user.
:-)
--
-- Blair MacIntyre, Professional Leech on Society ( aka CS Graduate Student )
-- bmacintyre@{watcgl, violet}.{waterloo.edu, UWaterloo.ca}xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (09/10/90)
bmacinre@watcgl.uwaterloo.ca (Blair MacIntyre) writes: >Just a quick note: >The guy who is porting Gnu Emacs put up version 0.3 Beta, which corrects >a few very important problems: >- no more busy wait! >- uses Amiga ENV:TERM instead of Manx env variables. > >So, if you want to play with it, it's almost usable now. Of course, the >thing still takes 3 minutes to load, so it's not for the casual user. >:-) Hmmm. My sysadmin friends who use GNUemacs just fire it up once at the beginning of the day and never leave it, so in a system with a lot of memory, the three minutes might not be a big deal. Have you tried it enough to know if it can be used the same way on the Amiga (spawn all other jobs from within GNUemacs and capture the output into edit buffers as needed)? This could be a real productivity environment for software development, if so. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
kutem@motcid.UUCP (Jon Kutemeier) (09/10/90)
Ran into a problem with this version of GNU Emacs on an A3000 with 6 meg of memory (4 fast, 2 chip). It won't load unless I run nofastmem first. In fact, it crashes the machine! I get a yellow screen, and then have to reboot the machine. Any suggestions? -- Jon Kutemeier___________________________________________________________________ ------------------Software Engineer /XX\/XX\ phone:(708) 632-5433 Motorola Inc. Radio Telephone Systems Group ///\XX/\\\ fax: (708) 632-4430 1501 W. Shure Drive, Arlington Heights, IL 60004 uucp: !uunet!motcid!kutemj
bcphyagi@Twg-S5.uucp (Stephen Walton) (09/12/90)
In article <1990Sep9.174939.16737@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >[Can you] spawn all other jobs from within GNUemacs and capture the >output into edit buffers as needed)? Unfortunately, the porter says in the latest README that he doesn't have code yet to do this. -- Stephen R. Walton, Dept. of Physics and Astronomy, Cal State Northridge I am srw@csun.edu no matter WHAT the stupid From: line says!
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (09/12/90)
bcphyagi@Twg-S5.uucp (Stephen Walton) writes: >xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >>[Can you] spawn all other jobs from within GNUemacs and capture the >>output into edit buffers as needed)? > >Unfortunately, the porter says in the latest README that he doesn't >have code yet to do this. Thanks. Probably wasn't the most sensible question in the world anyway. That was an important advantage of GNUemacs on a text only monitor with one window into the system. On the Amiga, as long as I "run" GNUemacs, I can do most of the same thing by pushing the window back and exposing a Shell window (though that doesn't capture output to the CLI into a buffer for me). It _would_ be handy if the window for GNUemacs resized nicely, at least. Then one could fire it up, push it out of the way, and pull it open again as needed (iconification would work nicely too). Both ways you get the "run all day" advantage with only one startup time to pay, even if it _is_ 3 minutes, if you have the memory to spare. Sorry for the muddled viewpoint in my prior question. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> -- "Don't post when your tired, Kent." "But I'm _always_ tired." "That's because you're _always_ posting."