🚀 go-pugleaf

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