🚀 go-pugleaf

/* Written  6:35 am  Dec 31, 1988 by Dave@imagine.UUCP in hcx3:comp.emacs */
/* ---------- "startup.el" ---------- */
> 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.

There is a reason for this.  Among other things, there are several
variables that affect the behavior of startup.el:

<apropos>	inhibit-startup-message	      
<apropos>	  Variable: *Non-nil inhibits the initial startup messages.
<apropos>	inhibit-default-init	      
<apropos>	  Variable: *Non-nil inhibits loading the `default' library.
<apropos>	term-setup-hook		      
<apropos>	  Variable: Function to be called after loading 
<apropos>	            terminal-specific lisp code.

The way it is done allows your ~/.emacs to inhibit certain default actions.

As a solution for your problem, wrap your global key bindings in a
function, and setq term-setup-hook to it:

	(defun set-SS3-keys ()
		"Unconditionally bind SS3 keys for emulation"
		;code here
	)
	(setq term-setup-hook 'set-SS3-keys)

Another way of doing it would be to load the term code yourself, and then
setq term-file-prefix to nil:

	(load-library <library name>)
	(setq term-file-prefix nil)

By the way, this is what startup.el has to say about it:

<startup.el>    ;; Load library for our terminal type.
<startup.el>    ;; User init file can set term-file-prefix to nil to 
<startup.el>    ;; prevent this.


> 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 most kludges, it sucks.  It defeats the purpose of the design of
startup.el.

> 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.

Don't you dare move the terminal code from startup.el.  It is there for a
reason: so it can be inhibited or otherwise superceeded.

> Should the order in which .emacs is read be changed?

Definitely no.

One more thing.  In case your startup.el and mine differ, my GNU is

	GNU Emacs 18.52.10 of Wed Nov 16 1988 on hcx3 (usg-unix-v)


HAPPY GNU YEAR

--Roberto
______________________________________________________________________________
                               ||   Internet: shirono@ssd.harris.com
     Roberto Shironoshita      ||
      Harris Corporation       ||             ...!novavax---\
   Computer Systems Division   ||   UUCP:     ...!uunet-------!hcx1!shirono
                               ||             ...!mit-eddie-/
------------------------------------------------------------------------------
DISCLAIMER: The opinions expressed here are my own; they in no way reflect the
            opinion or policies of Harris Corporation.