[comp.sys.atari.st] Problem with gnu emacs.

jones@ils.nwu.edu (Eric Jones) (12/10/90)

Hi, I have been running Edgar Roeder's port of gnu emacs V18.55 to the ST.  
Overall I'm very happy with it,  but I have encountered a couple of
annoying problems.  This message is to ask if anyone has found patches or 
work arounds. 

1. Filename completion causes the disk to thrash.  The disk seems to do at 
least one, (sometimes two), seeks for each file in the directory in which
the filename is being completed.  With my sluggish supra drive, filename
completion can cause the system to hang for 30 seconds or more.

2. Emacs sometimes crashes when it receives two quit signals (^G) in 
succession.  This usually happens in the minibuffer, but beyond that I
haven't been able to discover any general pattern.  Actually, it's possible
that emacs is not actually crashing.  What usually happens is that I get 
thrown into gulam with some kind of weird error message, and then am unable
to get back to emacs: ^Z causes the system to hang.

I have a Mega 2 ST and run emacs from gulam; gulam is in my auto folder.

One more question: is there any way to take advantage of the blitter chip and
speed up screen updates when running emacs?

Thanks, 

       Eric Jones (jones@ils.nwu.edu).

entropy@ai.mit.edu (entropy) (12/10/90)

In article <166@anaxagoras.ils.nwu.edu> jones@ils.nwu.edu (Eric Jones) writes:
   Hi, I have been running Edgar Roeder's port of gnu emacs V18.55 to the ST.  
   Overall I'm very happy with it,  but I have encountered a couple of
   annoying problems.  This message is to ask if anyone has found patches or 
   work arounds. 

   1. Filename completion causes the disk to thrash.  The disk seems to do at 
   least one, (sometimes two), seeks for each file in the directory in which
   the filename is being completed.  With my sluggish supra drive, filename
   completion can cause the system to hang for 30 seconds or more.

I would doubt there's an easy fix for this.  It doesn't sound like a
problem with Gnu EMACS, more like a problem with running it on a small
computer.  Try using a disk cache, so all that grinding will be done in
memory.

   2. Emacs sometimes crashes when it receives two quit signals (^G) in 
   succession.  This usually happens in the minibuffer, but beyond that I
   haven't been able to discover any general pattern.  Actually, it's possible
   that emacs is not actually crashing.  What usually happens is that I get 
   thrown into gulam with some kind of weird error message, and then am unable
   to get back to emacs: ^Z causes the system to hang.

Believe it or not, it's supposed to do that.  On a multitasking system
you could re-attach to the process, but in TOS I'd assume you're just
plain screwed.  The reason behind this is so you have a way to "REALLY
get out" in case Emacs gets confused and starts trashing your file
system or something.  The fix is to become much more mellow about
pressing C-g (just once will usually do the trick.)  I'm still
re-learning this is myself as older versions of GNU Emacs didn't do
this (A friend and I just installed 18.55 on a VMS machine, which had
version 16.somethin-or-other, and I ghot nailed by this a few times.)

Disclaimer:  I use GNU Emacs on a day to day basis, but rarely use it
on my ST.  And, the version I have on my ST was a different port.  So,
my statements here reflect only my knowledge of GNU Emacs in general,
not of any specific port.

entropy@mole.ai.mit.edu

ralph@laas.fr (Ralph P. Sobek) (12/10/90)

Do you guys use Edgar Roeder's net posted version or a more recent
version of GNU emacs?  A)  I do *not* have that disk thrashing
problem; just an ols SH204, and B)  though the posted version died
quite easily out from under me, Edgar sent me a version stating that
the 2 posted net patchs should *not* be applied.  Maybe that version
has been posted somewhere (like atari.archive).  If not, I could
always try.

--
Ralph P. Sobek			  Disclaimer: The above ruminations are my own.
ralph@laas.fr				   Addresses are ordered by importance.
ralph@laas.uucp, or ...!uunet!laas!ralph		
If all else fails, try:				      sobek@eclair.Berkeley.EDU
===============================================================================
Reliable software should kill people reliably! -Andy Mickel, Pascal News #13,78