Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

I take advantage of the fact that a .emacs file has higher precedence than a .emacs.d/init.el file for this. All the common stuff lives in the .emacs.d directory and is under source control. The little bit of work/machine specific stuff I have goes in the .emacs file, which wraps a

    (load "~/.emacs.d/init")
My home machines don't need anything special, so there's no .emacs file and the .emacs.d/init.el file just gets loaded directly.


sort by: page size:

I have an emacs.d, which is a superior alternative to a .emacs.

The basic init.el file loads my various language modes, and some other minor modes (e.g., tempbuf-mode). It also loads a bunch of files from the "emacs.d/my_lisp" directory which contains various overrides and new functionality attached to existing modes (e.g., icicles customization, assorted one-off functions I want to add to modes). Lastly, it loads a bunch more files from my emacs.d/lisp directory which implement custom functionality.

For example, the current emacs M-x eshell doesn't behave the way I like. I often want multiple shells, so I've build a "ring of shells" functionality: f6 cycles through the ring of shells, C-f6 creates new shell window in the ring. I did something similar with window configurations.

Also, the emacs.d stores all modes which I use regularly. So when I migrate to a new computer, all I need to do is

    darcs get me@oldbox:emacs.d
and tweak a few settings.

Cool. Can you show how you start an Emacs (i.e., what flags you use) to test whether init.el would load successfully next time an Emacs is started the normal way?

So each time you launch emacs you have to point it to your init file?

This is true. I might refactor the codebase to do what you're suggesting in the future.

For now I just pushed a new v1.1.0 release that automatically detects and supports ~/.emacs.el and ~/.emacs.d/init.el in addition to ~/.emacs as configuration file locations.

That should fix this problem for most people for now although I agree that your suggestion is probably more robust overall.


That is your.emacs.d, I presume? I am still mostly carrying around a .emacs and not using init.el.

That said, played with this some today and I see that I can get my startup down to about 5 seconds on my old netbook. Not too bad, all told. (This computer is hilariously slow.)


I found it really helpful to break my .emacs up into several files. Aside from trying to load .emacs, it will also try .emacs.d/init.el -- mine sets up the load path and then loads .emacs.d/my-options.el, etc. That way, the sprawling growth stays compartmentalized.

No guarantees this will work on xemacs, older versions of GNU emacs, or whatever, but here's what I use (some of which is adapted from the excellent Emacs wiki (http://emacswiki.org):

    (push "~/.emacs.d/" load-path)          ; my init files
    (push "~/.emacs.d/elisp/" load-path)    ; other elisp pkgs
    
    ; byte-compile files in ~/.emacs.d/ whenever we change them
     (defun byte-compile-init-files ()
       (when (and
              (string-match "/\.emacs.d/" buffer-file-name)
              (string-match "\.el" buffer-file-name))
         (when (file-exists-p (concat buffer-file-name ".elc"))
           (delete-file (concat buffer-file-name ".elc")))
         (byte-compile-file buffer-file-name)
         (if (get-buffer (concat (buffer-name) "c")) ;.el -> .elc
             (kill-buffer (concat (buffer-name) "c")))))
    (add-hook 'after-save-hook 'byte-compile-init-files)
    
    ; don't disable commands or mess with my init, grr grr
    (setq disabled-command-function 'nil)
    
    (defun my-load-wrap (fname)
      "Compile stuff if the .el file is newer than the .elc, and load."
      (let* ((fpath "~/.emacs.d/")
             (fn (concat fpath fname ".el")))
        (if (not (file-readable-p fn)) 
            (message (concat "File " fname " does not exist!")))
        (if (or 
             (not (file-readable-p (concat fn "c")))
             (newer-file (file-last-mod-time fn)              ;some .el
                         (file-last-mod-time (concat fn "c"))))     ;compiled
            (byte-compile-file fn t)     ;compile and load
            (load fn t))))               ;load with failsafe
    
    (my-load-wrap "my-options")                   ; general options
    (my-load-wrap "my-functions")                 ; my misc functions
    (my-load-wrap "my-server")                    ; emacs-server stuff
    (my-load-wrap "my-calendar")                  ; cal/diary options
    (my-load-wrap "my-bindings")                  ; and lots of 'em
    (my-load-wrap "my-packages")                  ; misc packages
    (my-load-wrap "my-text")                      ; text mode hooks
    (my-load-wrap "my-programming")               ; python, c, lisp, ocmal, etc
    (my-load-wrap "my-web")                       ; for browsing w/ w3m
    (my-load-wrap "my-irc")                       ; rcirc stuff
    (my-load-wrap "my-skel")                      ; skeletons, boo

    ; load my-aesthetic last, so if there's an error the
    ; faces don't get set, and to ensure faces from all packages exist
    (my-load-wrap "my-aesthetic")                 ; faces, interface stuff

Not that different; Emacs without complex ~/.emacs.d/init.el loads quite quickly (in unscientific testing on my dev VM with a cold cache, 214ms for "emacs -nw -Q -e 'kill-emacs'").

I use the same `.emacs` on both Windows and Linux. I put some Windows-specific stuff in a separate file that I load only when `(string-match "nt" (symbol-name system-type))`.

Sure, the .emacs script could be just as good an init as any.

I have both an early-init.el and init.el in my .emacs. In the former I turn off package loading on startup, but also set most UI variables so menus etc are turned off before the frame is shown (stuff you might once have done with Xresources). This is also where you might do more extreme performance related tweaks (e.g. to the GC) if you really care about startup time. My init.el then does package-initialise and is mostly use-package calls.

I've been using Emacs for more than 30 years and my init file is mostly loading and configuring extra packages, and not customizing the editing behavior. I have no problem working in a basic "emacs -q" session (which skips loading the init file) when I don't want to "pollute" my main session (eg. working with huge logs/dumps).

You should use `use-package` to manage your packages and defer their loading to when you use them. I have over 100 packages in my init.el and my Emacs loads in less than a second.

When I started out, I think I somehow was under the impression that .emacs.d was some sort of cache, and not for end-users to mess with. Actually, I feel like when I first started out on Red Hat 5 it wasn't there, but I probably just wasn't being very observant.

At some point I set up auto-insert for a variety of files, and the howto I found used the directory .autoinsert, and at the moment that's actually where my elisp that isn't in my .emacs lives. It's a little hacked together and ad hoc, but not worth my time to fix. Nowadays I've customized everything I want to, and mostly am installing thirdparty packages.


Emacs out of the box works.

Unfortunately there is a misconception that you need a 10kloc init.el to be productive. Worse still are the opinionated configurations targeted at newbs.


Run vanilla Debian. Build emacs from scratch if a new version has something you need, or if you like shiny.

Only fuck with your init.el if you really want/need to.

I've had the same init.el for almost a decade.


Pretty soon you'll be able to set your init process to just be emacs.

I often reach for

  emacs -nw -Q
It boots up quickly and the basic editing defaults are all there. Has the advantage of being everywhere Emacs already is as well

But why? We have an emacs init process that is fast enough, why not put your init script in version control and bootstrap emacs this way?

My .emacs on this machine is almost literally this:

  (custom-set-variables
   '(indent-tabs-mode nil)
   '(inhibit-startup-screen t)
   '(menu-bar-mode nil)
   '(show-paren-mode t)
   '(tool-bar-mode nil))
On my home computer I have somewhat more involved .emacs, but apart from the above (and huge list of totally random variables picked up by customize-save-customized since 2003) it consists of long-irrelevant compatibility hacks and somewhat complex logic for creating correctly sized frames on additional X displays (which I stopped really using when I got 4k monitor)
next

Legal | privacy