startup.el

startup.el

Post by Dave Lawrenc » Sun, 02 Dec 1990 12:35:00



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

 
 
 

startup.el

Post by Robert Krawi » Tue, 02 Jan 1990 17:21:00


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

bloom-beacon >  |think!rlk   (postmaster)            Cambridge, MA  02141
topaz >>>>>>>>  .       Thinking Machines Corp.         (617)876-1111

 
 
 

startup.el

Post by John Robins » Tue, 02 Jan 1990 19:45:00




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

 
 
 

startup.el

Post by Phil Ritzenthal » Tue, 02 Jan 1990 15:00:00



> 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

"Research is the process by which a loose brick is found through pounding one's
 head against a wall."  --  Anonymous

 
 
 

startup.el

Post by ec » Tue, 02 Jan 1990 21:03:00


Phil Ritzenthaler 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

 
 
 

startup.el

Post by shir.. » Tue, 02 Jan 1990 16:23:00



/* ---------- "startup.el" ---------- */

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

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

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

Quote:> 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
______________________________________________________________________________

     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.