Dave Lawrence (12/31/88)
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.edurlk@think.com (Robert Krawitz) (01/04/89)
In article <2225@imagine.PAWL.RPI.EDU>, Dave Lawrence writes:
]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.
Emacs does the correct thing by loading your .emacs file first. If
term-file-prefix is nil, emacs will not attempt to load the terminal
initialization file.
What you should do is load whatever terminal setup code you wish (you
can crib code from startup.el if you want to load the terminal init
file and overload it with your stuff) and set term-file-prefix to nil.
This will inhibit loading the terminal setup file.
Note that if your .emacs file is loaded after the terminal init file,
the latter could mutate your environment in undesirable ways before
you can do anything about it. The way the startup sequence works now,
you have first and last crack at your environment.
]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.
There's about 5 lines of code involved.
--
harvard >>>>>> | Robert Krawitz <rlk@think.com> 245 First St.
bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02141
topaz >>>>>>>> . Thinking Machines Corp. (617)876-1111jr@bbn.com (John Robinson) (01/04/89)
In article <35065@think.UUCP>, rlk@think (Robert Krawitz) writes: >In article <2225@imagine.PAWL.RPI.EDU>, Dave Lawrence writes: >]I honestly don't understand why .emacs is not the last elisp file loaded ... > >Emacs does the correct thing by loading your .emacs file first. If >term-file-prefix is nil, emacs will not attempt to load the terminal >initialization file. ... and if you need something eval'd after the terminal-dependent files are loaded, hang it on term-setup-hook. You can even put all of your initialization there if you are so inclined. ;-) -- /jr jr@bbn.com or bbn!jr
phil@tut.cis.ohio-state.edu (Phil Ritzenthaler) (01/04/89)
In article <35065@think.UUCP>, rlk@think.com (Robert Krawitz) writes: > > What you should do is load whatever terminal setup code you wish (you > can crib code from startup.el if you want to load the terminal init > file and overload it with your stuff) and set term-file-prefix to nil. > This will inhibit loading the terminal setup file. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I REALLY don't think you want to do this! Instead, might I suggest what was done with Suns. In the sun.el file, about 1/2 way through, there are some simple lines: ;;; Since .emacs gets loaded before this file, a hook is supplied ;;; for you to put your own bindings in. (defvar sun-raw-map-hooks nil "List of forms to evaluate after setting sun-raw-map.") (let ((hooks sun-raw-map-hooks)) (while hooks (eval (car hooks)) (setq hooks (cdr hooks)) )) In another file, then, I have: (defvar sun-raw-map-hooks nil . . . ) (setq sun-raw-map-hooks '( (define-key sun-raw-map "208z" 'replace-string) ;; R1 . . . )) Which sets up the hook maps needed to remap the keys to what I want. This hook file is then loaded from the .emacs file. I was originally going to do what was previously mentioned and go in and change the startup.el file, but I thought that 1.) then I would have to remember to change it every time I installed a new version and 2.) it was time I learned how to work ==> WITH <== GNU Emacs and not against it. What troubles me is that these hooks are provided ONLY with the sun terminal file. After working with them, I can't understand why these aren't provided to the user for other defined terminals . . . rms?? Phil Ritzenthaler Advanced Computing Center for the Arts & Design (ACCAD) Systems Manager The Ohio State University UUCP: ...!{pyramid,killer}!grumpy.cgrg.ohio-state.edu!phil ARPA: phil@grumpy.cgrg.ohio-state.edu "Research is the process by which a loose brick is found through pounding one's head against a wall." -- Anonymous
ecb@utrccm (ecb) (01/05/89)
Phil Ritzenthaler writes: > In article <35065@think.UUCP>, rlk@think.com (Robert Krawitz) writes: > > > > What you should do is load whatever terminal setup code you wish (you > > can crib code from startup.el if you want to load the terminal init > > file and overload it with your stuff) and set term-file-prefix to nil. > > This will inhibit loading the terminal setup file. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I REALLY don't think you want to do this! Why not? I tried it and it seems to work fine. Bud Boman ecb@utrccm.smc.utc.com
shirono@hcx3.SSD.HARRIS.COM (01/06/89)
/* 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.