Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!apple!rutgers!mailrus!csd4.milw.wisc.edu!leah!itsgw!imagine!Dave
From: Dave Lawrence
Newsgroups: comp.emacs
Subject: startup.el
Summary: processing order might be a little messed up ...
Message-ID: <2225@imagine.PAWL.RPI.EDU>
Date: 31 Dec 88 11:35:30 GMT
Sender: news@imagine.PAWL.RPI.EDU
Reply-To: tale@pawl.rpi.edu
Organization: The Octagon Room
Lines: 36

I was about to send this off as a bug report and decided against
it, thinking someone here might convince me that this is a feature and
not a bug.
 
The scenario:  I want to unconditionally bind some global keys in my
.emacs file.  These keys emulate sequences sent from the vt100 keypad
(SS3).
 
The problem:  startup.el chews up .emacs before it reads in the terminal=
dependent stuff, so the global key map for the keypad gets completely
reset.  
 
I honestly don't understand why .emacs is not the last elisp file loaded ...
it only seems natural that a user should be able to undo things that
he doesn't like which are done by another start-up file.  I'd call it
a "programming oversight" rather than a bug.

I have a kludge, but I hate kludges like this ... I can run 
`emacs -q -l ~/.emacs'; in fact, I have an alias that says that now.
I can also load the file manually (blech) like I had to do when I
started this reply, because rn starts up emacs from $EDITOR.
 
As an aside, I don't use rnews because it doesn't work here.  Our
sys admins don't maintain the emacs hierarchy well here.
 
Does anyone have a suggestion?  I'd rather not have to move all of
the terminal code from startup.el (and then disable processing of
it in startup.el) because disk-space is very tight here -- every
page is important.  Should the order in which .emacs is read 
be changed?
 
Thanks in advance (again).
 
Dave
--
      tale@rpitsmts.bitnet, tale%mts@rpitsgw.rpi.edu, tale@pawl.rpi.edu