Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!edcastle!bjnw
From: bjnw@castle.ed.ac.uk (Brian Wylie)
Newsgroups: comp.emacs
Subject: Re: Problem with MICROemacs v.3.10 on SUN sparcstation
Summary: SUN's need the adjustmode() return values explicitly passed back
Keywords: ue3.10, SUN
Message-ID: <1465@castle.ed.ac.uk>
Date: 20 Dec 89 19:22:20 GMT
References: <49935@bbn.COM>
Reply-To: bjnw@castle.ed.ac.uk (B Wylie)
Organization: ~Gothic_ ~Enterprises_
Lines: 25

In article <49935@bbn.COM> OBERHAG@DD0RUD81.BITNET (Ruediger Oberhage) writes:
>As far as I can tell now it runs ok, but we have a problem with the (.emacsrc)
>startup file: certain commands (e.g. add-mode, add-global-mode, delete-mode and
>delete-window) execute but immedately abort the execution of the startup-file,
>i.e. it doesn't execute any command further down the lane.
>Ruediger Oberhage (it's me)                    Dep. of Theoretical Physics
>OBERHAG@DD0RUD81.BITNET                        University of Duesseldorf
>                                               Duesseldorf, Germany (West)

We have the same problem on all of our SUN workstations here, so I
suspect that it's a more universal problem.  In the file random.c are
several functions which themselves call the function adjustmode() --
they're called setmod(), delmode(), setgmode(), delgmode() -- with
varying parameters.  However, the return value of adjustmode() isn't
itself returned by the calling functions, so some rubbish from the stack
is returned instead, which is interpreted as an abort condition while
you're parsing your .emacsrc file (or any other file/buffer).  The
solution used here has been to enclose the adjustmode() calls within
return()'s for these cases.

It surprises me that no-one else has had this problem, since I'd have
thought that most other C compilers would have done the same.

  Slainte,                  "Now's the day, and now's the hour..."  
    Brian.                       "... Europe sans frontieres."