Here's my points on reducing emacs-init-time, this does not cover things like using a daemon or the server, it goes without saying that you should rarely ever close emacs.
Don't require packages in your init, if the package doesn't have proper autoload cookies, ensure you set up autoloads on the entry commands. So if the first time you use package ...
I ran into this the other day. I think it was caused by an invalid package archive file. The immediate fix is to delete <user-emacs-directory>/elpa/archives/melpa/archive-contents; it will be rebuilt on the next package-initialize. Unfortunately, package.el is not very robust to this sort of failure.
Op-ed: Windows is just slow.
I regularly use Emacs on both Windows (Cygwin and native) and GNU/Linux (Arch), and I've noticed this as well. I believe the answer is that Linux is just plain faster than Windows in a lot of areas, most notably in file system operations1 and threading/forking operations2.
I think the difference in performance is most ...
There's also a package on MELPA for this now: dashboard: https://github.com/rakanalh/emacs-dashboard. The package allows you to have a splash screen as in the image below:
Here's the use-package snippet from my config to set it up with a custom banner image and line of text, as well as a list of recent files and bookmarks:
One of the design choices in package.el was to try and make things "simple". Part of this is that package-initialize searches for all the packages that are installed, then tries to figure out which ones of those should be activated (according to pinning, and recency of versions in case where multiple versions of the same package are available), then loads ...
Whatever your .emacs and its improvements, you also should consider running emacs as a server at your session's opening :
Now, running emacs with
emacsclient -nw -c
or ... (see options) will be much faster
You can customize the value of initial-major-mode, which defaults to lisp-interaction-mode. Here's the variable's docstring:
initial-major-mode is a variable defined in startup.el.
Its value is lisp-interaction-mode
Major mode command symbol to use for the initial *scratch* buffer.
You can customize this variable.
For the ...
Manomagically :D, after posting the question I got the working solution by removing one single quote below in my .emacs
(setq initial-buffer-choice '(helm-recentf)) ;; Does not work
(setq initial-buffer-choice (helm-recentf)) ;; Works!!!
;; I still haven't tried doing with the built-in recentf only
(setq initial-buffer-choice 'helm-...
I believe it is standard practice for themes installed as packages to add their own paths to custom-theme-load-path as an autoload. A call to package-initialize will execute all of your package autoloads (among other things), and if there isn't an explicit call in your init file, it is called implicitly at the end of initialization.
I recommend putting a (...
Many of the included libraries are not loaded when you start up.
Some commands etc. are autoloaded, which means that Emacs recognizes them and knows how to load them. When you try to use a command that is autoloaded, Emacs then loads the library that defines it, if it has not yet been loaded.
You can create your own autoloads, whether for your own ...
In addition to the other answers (which explain how the majority of libraries are actually only loaded on demand), there is also the matter of the pre-loading of many core elisp libraries within the emacs executable itself, which provides an illusion of it loading a lot of things incredibly quickly.
This is achieved by running a so-called "bare" version of ...
Could anyone tell me how Emacs manages that, even with thousands .el-files?
Emacs "manages" that by not loading at startup thereby not holding up the loading of the core application. This in turn as the effect of returning keyboard control to the user faster.
But when is it loaded? On first use of that function, mode, or feature.
Doesn't it slow down? ...
The answer is rather trivial:
(mapc 'load (file-expand-wildcards "~/some-lisp-files/*.el"))
But as suggested above, it's always better to load just the code you are certain of, not even because it's more secure to do so, but because it could be too annoying to debug it if you introduce an accidental change etc. Worse yet, if some of those files contain ...
Something that recently popped up on emacs reddit: decrease the number of garbage collection invocations by putting this near the beginning of your init file:
(setq gc-cons-threshold 50000000)
(add-hook 'emacs-startup-hook 'my/set-gc-threshold)
(defun my/set-gc-threshold ()
"Reset `gc-cons-threshold' to its default value."
(setq gc-cons-threshold ...
neotree-mode is a major mode for the neotree buffer, and major mode functions do not take any arguments, so calling (neotree-mode t) is an error.
You wouldn't want to invoke that mode yourself, though -- it's only intended to be called from neotree's own buffer.
(Unlike minor modes -- it's very common to call a global minor mode directly from your init ...
From the emacs manual regarding packages:
By default, Emacs also automatically loads all installed packages in
subsequent Emacs sessions. This happens at startup, after processing
the init file.
So if your theme relies on some package initialisation you can put your call in after-init-hook. For example
Q also uses --no-site-lisp. See the Emacs manual, node Initial Options.
For information about X resources, see node Resources.
Learn to ask Emacs: C-h r, then i and type some text to match an index entry, then TAB to see the matches, and choose one.
You can find i and other manual-browsing keys by doing C-h m in the manual. C-h m in any mode gives you ...
Replace '(progn ...) with (progn ...)
By putting the quote there you are specifically telling emacs NOT to evaluate the code in your progn. In fact you don't need progn at all. It looks like you are trying to treat with-eval-after-load like eval-after-load. Note the signature differences:
(with-eval-after-load FILE &rest BODY)
You can unload the system prolog mode first, this unbinds all its variables, so that the new defvar init-forms will take effect:
(when (version< prolog-mode-version "1.25")
Note that unload-feature is not a commonly used function, so it's possible you may hit some ...
You can customize option initial-buffer-choice (using M-x customize-option).
The value can be a buffer name (the name of your calendar buffer, if it exists - e.g. "*Calendar*") or a function that returns a buffer. The buffer is displayed in place of the welcome (aka "splash") screen.
It is of course up to you to ensure that when you start up Emacs the ...
The time you spend optimizing your startup time will likely be greater than all the extra time you would have otherwise waited for Emacs to start up.
At the moment I make 25 require calls in my init file so that Flycheck can find spelling errors in my code. My startup time is...
$ time emacs --eval '(save-buffers-kill-terminal)'
Place two lines at the bottom of your .emacs file using find-file and adjust the path to the file locations. If you want them loaded in the background only, then use find-file-noselect instead of find-file -- that way, they will not interfere with your current display window/buffer screen setup at startup.
You should be able to see it in *Messages* buffer.
You can use SPC w p m (Spacemacs specific) or C-x 4 b to visit that buffer in another window (or C-x b to visit it in the same window). (When prompted for the buffer name completion is available: *Me TAB.)
The problem you describe about package-initialize taking so much time to load is a well known problem. It is also one of the problems that some emacs frameworks try to solve by loading the autoloads manually.
I see two solutions to your problem.
Write (or extract from a framework) the functionality to set the paths and load the autoloads of the packages ...
Correct; this option is not relevant to the fully-built emacs executable, because that library (and the many others it pulls in with it) are pre-loaded in that executable.
You can, if you so wish, create your own custom executable by modifying the sources before the dumping process occurs.
C-hig (elisp) Building Emacs RET
The initial-buffer-choice mechanism in startup.el makes some assumptions that may not fit your use case.
Here's a quick overview of how Emacs decides what buffer(s) to display at startup:
Command-line arguments are processed so that any files specified are opened in new buffers. These buffers are added to a list of displayable buffers.
M-: (fancy-about-screen), or call (fancy-about-screen) from your Lisp code.
It shows this:
This is GNU Emacs, one component of the GNU operating system.
GNU Emacs 24.5.1 (i686-pc-mingw32)
of 2015-04-11 on LEG570
Copyright (C) 2015 Free Software Foundation, Inc.
Authors Many people have contributed code included in GNU Emacs
Contributing How to ...
1) I have found esup to be a very convenient for Emacs startup profiling.
You just run M-x esup and get back list of all expressions in your init.el sorted by the time they took to execute. You don't need to restart Emacs or add anything special to the config, so narrowing on the slow down suspect becomes much easier.
2) I (use-package :defer t) all the ...