I use Emacs v. 22 (the console version, either remotely with PuTTY or locally with Konsole) as my primary text editor on Linux. It takes a while to load up each time I start it though, probably almost a second, although I never timed it. I tend to open and close Emacs a lot, because I'm more comfortable using the Bash command-line for file/directory manipulation and compiling.
How can I speed up the start-up time?
Others have covered using gnuserve and emacsclient, and I'd suggest compiling within emacs (being able to jump to compilation errors is a win).
But, specifically speeding up the .emacs can be done by:
Byte compiling the .emacs file, which you can do automatically by using this snippet of code
Replacing as many of the (require 'package) statements with autoloaded functionality. This will delay loading of lisp until it's actually required. Using this technique allowed me to speed up my startup from >6 seconds to <1. This takes a little bit of work because not all libraries come properly marked autoload.
Removing code/functionality you no longer use.
Try running emacs with the option --no-site-file to avoid loading unnecessary packages in the site installation site-start.el.
If you are really serious, you can roll your own emacs with your favorite functionality already loaded. This, of course, means it's more involved to make changes to what you have in your .emacs because it's a part of the binary. Follow the link for information on how to use dump-emacs.
Buy a faster computer and/or faster disk.
How to determine what your .emacs loads
Now, how do you find out what your .emacs loads? With the goal to remove the functionality, or to delay it? Check your *Messages* buffer, which contains lines like:
Loading /home/tjackson/.emacs.tjackson.el (source)...
Loading /home/tjackson/installed/emacs/lisp/loaddefs.el (source)...done
Loading /user/tjackson/.elisp/source/loaddefs.el (source)...done
Loading autorevert...done
Loading /home/tjackson/.emacs.tjackson.el (source)...done
If you'll notice, the Loading statements can nest: the first .emacs.tjackson.el ends with ... and the last line shows the .emacs.tjackson.el load is ...done. All those other files are loaded from inside my .emacs.tjackson.el file. All the other loads are atomic.
Note: If you have a large .emacs, it's possible that the *Messages* buffer will lose some of the messages because it only keeps a fixed amount of information. You can add this setting early on to your .emacs to keep all the messages around:
(setq message-log-max t)
Note: It the 'load command will suppress the messages if its fourth argument nomessage is non-nil, so remove any such invocations (or, advise 'load and force the fourth argument to be nil).
In addition to Adam Rosenfield's solution, I recommend to use Emacs in server mode. You may add (server-start) to your dotemacs, and run emacsclient instead of emacs whenever you want to open file in Emacs. That way you have to pay the loading cost of Emacs only once, after then clients pop up immediately.
Edit
You're right, v22 does not create a new frame. Create a shell script that do the trick:
#!/bin/bash
# Argument: filename to open in new Emacs frame
/usr/bin/emacsclient -e '(let ((default-directory "`pwd`/")) (select-frame (make-frame)) (find-file "'$1'"))'
Edit 2
In v24+, you can do emacsclient -c to create a new frame.
Don't close Emacs every time you want to use the shell. Use Ctrl-Z to move Emacs to the background and the fg command in Bash to move it back to the foreground.
A couple of tips:
Use autoloads
Using autoload saves you from loading libraries until you use them.
For example:
(if (locate-library "ediff-trees")
(autoload 'ediff-trees "ediff-trees" "Start an tree ediff" t))
Compile your .emacs
Gives you a slight speed increase although there are pitfalls if you
work with version control and your .emacs is newer than .emacs.elc.
One common trick is:
(defun autocompile nil
"compile itself if ~/.emacs"
(interactive)
(require 'bytecomp)
(let ((dotemacs (file-truename user-init-file)))
(if (string= (buffer-file-name) (file-chase-links dotemacs))
(byte-compile-file dotemacs))))
(add-hook 'after-save-hook 'autocompile)
Learn to love emacs server.
Running emacs as a server means never having to close it down. However
I note your still using emacs22. emacs23 supports multi-tty which makes
it a lot easier to run emacs in one screen session and then bring up
new windows in another terminal. I use emacs to edit mail for my mail
client (mutt) and emacsclient is fantastic for these sort of quick edits.
One of
M-x shell
M-x eshell
M-x term
M-x ansi-term
should meet your command-line needs from within Emacs.
You can also use M-! (aka M-x shell-command) to execute a one-liner without dropping to the shell.
Check your .emacs file to see if you're loading unnecessary packages. Loading packages can take a significant amount of time. For example, you might only want to load the php-mode package if you're editing a PHP file. You can do that by installing a hook procedure, although I'm not certain of the details.
Also make sure that any packages you're loading are compiled (.elc files). You can compile an elisp file by running
emacs -batch -f batch-byte-compile thefile.el
Compiled packages load much faster than uncompiled packages.
"I tend to open and close emacs a lot, because I'm more comfortable using the bash command line for file/directory manipulation and compiling."
You're describing the way an editor like vim is used like. Shoot in&out. Emacs is usually kept open, and mostly all is done from "within it". hiena already answered what would be the correct approach here.
The fastest way is to profile your .emacs. I cut down my load time from >3s to 1s in 5 minutes after I found that 4 particular lines in my .emacs were taking up more than 80% of the load time.
One thing that helped me reduce the load time of my .emacs, in addition to autoload (as others have suggested), is eval-after-load. In the following example, delaying the call to sql-set-product saves you from having to load sql in your .emacs, making the exisiting sql autoloads more effective.
(eval-after-load "sql"
'(progn
(sql-set-product 'mysql)
(setq sql-mysql-options '("-C" "-t" "-f" "-n"))
(setq sql-sqlite-program "sqlite3")
))
Of course, for some packages there will be a hook available that you can do the same thing, but sometimes there isn't, or else this way just proves easier to think about.
Emacs is designed to run "all the time" (or at least for long periods of time), thus starting and stopping Emacs several times during a day is not recommended.
I would suggest using screen. Screen is a terminal multiplexer, giving you an unlimited virtual terminals in one terminal.
After installing simply write "screen emacs" in your terminal. Emacs will start as usual, but pressing "c-a c" (that is press ctrl-a and then c) will open a new virtual terminal. You can get back to emacs by pressing "c-a c-a" (that's two times ctrl-a).
You can even detach from the running screen session, the key sequence is "c-a d".
Re-attach to the session by issuing "screen -R" and you will be back where you left. This enables you to start an emacs session at work, detach, go home, and re-attach from home.
I've been running Emacs like this for months in a row.
Here's the official web site: http://www.gnu.org/software/screen/ but try googling for screen tutorials and howtos
You can use benchmark-init to profile your Emacs startup. It will keep track of what modules are being loaded and how much time is spent on each. The results can be presented either in a tabulated form or as a tree. The tree makes it easier to track who loads what, which can be helpful when you load a package with a lot of dependencies, and the tabulated form helps you quickly find where most of the time is being spent.
Once you have these results try to figure out if all of the modules have to be loaded all the time or if you can perhaps load some of them on-demand. For instance, in my configuration I only load Emacs extensions that are specific to certain modes when that mode is actually activated since most of the time I only use a small subset of them in a session. eval-after-load and mode hooks will be your friends here.
By applying this method my Emacs starts in 3-4 seconds and I have close to 200 extensions installed. Most of the time is spent loading Helm, which I always load since it replaces find-file and other core functions that are always needed, and CEDET, since I use the latest version and it has to be loaded before Emacs tries to load the older built-in version.
Try using the https://github.com/jwiegley/use-package macro to define your package loads and customizations. It handles deferred loading of packages for you, making it relatively easy to get good startup times even in the presence of large numbers of configured packages. I have almost 100 packages referenced in my .emacs, but my startup time is under 2 seconds on Linux, and 2.2s on the Mac.
One thing that others haven't mentioned is to include the elisp libraries you use as part of the dumped Emacs to move the library loading time from Emacs startup to Emacs build. It is not for the faint-hearted, but if you load several libraries in .emacs it could win you a few seconds of startup time.
I had around 120sec start time. I was able to find the fix installing this:
https://github.com/dholm/benchmark-init-el
put on top of your init.el
(let ((benchmark-init.el "~/.emacs.d/el-get/benchmark-init/benchmark-init.el"))
(when (file-exists-p benchmark-init.el)
(load benchmark-init.el)))
then once your emacs started, run:
M-x benchmark-init/show-durations-tree
On my side the problem was 127 secs in tramp-loaddefs
I fixed it by adding
127.0.0.1 host.does.not.exist
to /etc/hosts and that made my startup fast
see more here: https://github.com/emacs-helm/helm/issues/1045
another thing that maybe helpful to you: https://www.emacswiki.org/emacs/ProfileDotEmacs
This doesn't answer the question, but is kind of relevant
I don't know how to make it start faster, but there are a few things I could suggest:
for most things you do on the command line, you can do them in emacs:
compile: M-x compile, then type the command you use
my experience is only with C++, but with g++ you can press C-x ` to jump to lines that the compiler complains about
run shell commands: M-!, dumps output into a buffer
interactive shell: M-x shell
alternatively, you could run emacs like this:
emacs file.ext &
which opens emacs in the background so you can still use the shell ( this works best with putty and X forwarding with something like Xming)
I was trying to solve the same problem, when I came across this question here. I just wanted to add that the problem for me was not because of the load time of emacs lisp packages, but the fact that the host did not have a fully resolved hostname
To check your package load time do
M-x emacs-init-time
For me it was 0.3 seconds, and yet the load time was extremely high.
After changing my hostname correctly, it fixed the problem.
To configure your fully resolved hostname edit /etc/hostname, and /etc/hostsfile with:
127.0.0.1 localhost localhost.localdomain
192.168.0.2 hostname hostname.domain
I would have to check my customization, but there is a package called gnuserve or emacsclient. It migrates a lot so you will have to google for it.
It runs one emacs session in the background. Any further sessions of emacs are essentially just new frames of that session. One advatage is quick startup times for your later sessions.
I have a number of splits open, looking at various buffers. But when I for example check the help on a function it will replace one of the splits with the help buffer. Once I'm done reading the help I have to go back to the correct buffer manually which is a pain. How do I get Emacs to be nicer to my buffers?
Update: Help will let you press q to go back to the previous buffer. But causing the Emacs backtrace to pop up also steals one of my buffer windows and it doesn't have a q.
Update: Backtrace DOES have q to go back. My original question still remains: how do I ask Emacs not to steal one of my splits?
Adding the line(push "*Help*" special-display-buffer-names) to the init file should make subsequent invocations of the help buffer to appear in its own frame(what the desktop usually calls "window"), and leave the original frame with its configuration alone.
See Special Buffer Frames.
You could also use winner-mode. It came up on planet.emacsen.org a while back.
Winner Mode is a global minor mode. When activated, it allows to “undo” (and “redo”) changes in the window configuration with the key commands ‘C-c left’ and ‘C-c right’.
That way you can undo any changes to your splits immediately after they happen.
I hope this will help you :
C-x 0 to remove the current window
C-x 1 to keep only the current window
you can use windmove by adding the following line in your .emacs :
(windmove-default-keybindings)
Then, you can move the point between windows using S-right S-left S-up and S-down
There are lots of ways to store and restore emacs windows, see emacswiki.org on the subject.
What I do is just go to that changed buffer, C-x k it, and the current buffer in that window will be the previous buffer.
It may be possible to define advice for the help that saves the current window and buffer state and restores it with a simple keybind. But this is outside my basic elisp knowledge.
I've recently upgraded from Carbon Emacs (v22.3) to vanilla Emacs 23.2 (from http://www.emacsformacosx.com). On Carbon Emacs when compiling a project, The frame is split in two with the current source file/SConscript in the top window, and the compile output in the bottom window. I'd hit C-x ` to navigate to the first warning or error in the compile output and it would replace whatever was in the top window with the source file the error or warning is in.
In Emacs 23.2, however, a 3rd window is opened causing two windows open in the top half of the frame (split vertically) and the compile output in the window of the bottom half of the frame. How do I tell Emacs to not open a new window and instead open the code in the the existing non-compiler output window in the frame?
A little further clarification on the behavior that I just noticed. If I hit C-x ` while the buffer containing the source file or SConscript file is active, no new window is opened. It's only if I'm manually navigating through the *compilation* buffer and hitting enter on an error or warning, or mouse clicking on a warning when a third buffer window appears.
The function which is used in next-error functionality is pop-to-buffer which in turn uses split-window-sensibly. You can control the behavior of split-window-sensibly by adjusting the variables split-width-threshold and split-height-threshold.
In your case it is split-width-threshold which is too small. In my emacs 23.1 it is set to 160. Just set it to a larger number and the problem should be solved:
(setq split-width-threshold 200)
I can't reproduce this problem myself, but you might try the following:
(setq split-width-threshold nil)
This tells display-buffer never to split windows horizontally, even if they are quite wide. There is also a split-height-threshold variable which is handled similarly. Checking these variables' current values might suggest whether they could be relevant to the behavior you're seeing.
One last thing to check: if you have defined your own display-buffer-function, that could be making these decisions for you.
When I start Emacs, its windows and its minibuffer start up floating on the main frame, leaving a lot of empty space (see: here and here). Any idea of what is going on and how to fix it?
I'm using emacs version 23.1.1 on Xmonad
Thanks!
I get the same thing occasionally when doing a TAB expand in shell mode. I don't end up with an empty mini-buf, it usually has all the contents from the shell expand. The only solution I've found so far is to kill the current shell buffer
You might try C-l (recenter-top-bottom). I've used this over the years as a pretty reliable "repaint" operation that will clear up various detritus that occurs on the frame. It is even more helpful when you do not have a window system.
It looks like an odd interaction between Emacs and your window manager. It's as if Emacs is configuring itself to have a certain number of lines and columns in its active window, but the frame the window manager has allocated it is larger.
Can you try running X without Xmonad (ie. just run startX) and then run Emacs? You won't get frame decorations, but you can still use xterm to start it and see what 'natural' size it gets allocated. With the same Emacs configuration, that would narrow it down to some issue with Xmonad.
It's not obvious from the screenshots, as one is definitely in GUI mode, but the other (green on black) looks like it is in text mode. If you force it to run in text mode (emacs -nw), does it take up the same size? Within the shell, do normal commands take up the entire size of the allocated window?
Are the shell variables COLUMNS or LINES set correctly? Do they match the window dimensions? Assuming you are running bash, is shopt checkwinsize turned on? Do regular commands such as ls wrap at the expected margins and scroll to use the entire window?
It is worth ensuring that text mode is being configured correctly before getting GUI mode to work. I have a hunch the way that Xmonad is managing its window sizing may be the culprit, if it is 'forcing' windows to tile in certain arrangements, and the correct X hints aren't being sent. But - that's all just supposition for now...
This partially works (taken from here):
(defun fullscreen ()
(interactive)
(set-frame-parameter nil 'fullscreen
(if (frame-parameter nil 'fullscreen) nil 'fullboth)))
(add-hook 'emacs-startup-hook 'fullscreen)
The windows get corrected, although the mini-buffer is still larger than the usual.
Sounds like a bug, to me. Consider reporting it: M-x report-emacs-bug. Try to provide a recipe starting from emacs -Q.
I'm having a problem with an Emacs lisp package that I pulled down from the ubuntu distribution. The package is JDEE, and it complains of Args out of range: "63", 0, 4 in the mini buffer and the *Messages* buffer whenever I open a file. This bug appears to have been reported last September but no action has been taken. I'm not an emacs newbie, having written some Elisp code myself, but I've never attempted to debug anything like this. I would like to stop the file load in a debugger when this error happens to at least get an idea of where the problem is coming from. I've read section 18.1.1 of the Elisp manual on "Entering the debugger on error" but trying to load the file after playing with various combinations of values for debug-on-error, debug-ignored-errors, and debug-on-signal appears to have no effect. Has anybody got any suggestions for my next step?
If debug-on-error isn't working, I'd start with the source itself. Find the keybinding/event that is causing the problem, and locate the function.
C-h k <keystrokes>
M-x find-function <function-name-from-above>
Now, once you are at the source
M-x edebug-defun
And the next time you hit the key, you should be able to step through the program. At that point, you can see which portion causes an error - and drill down that way.
You can also try setting the variable 'stack-trace-on-error to see if you can find the culprit (though 'debug-on-error usually works for me, not sure why it doesn't for you).
As a last resort (if edebug-defun doesn't work), you can redefine the routine with a call to (debug) in it, sort of does the same.
I suppose JDEE is somehow inhibiting debug-on-error. Perhaps grep through its files for the error message "Args out of range". While debugging, make sure to load the uncompiled .el files, not the byte-compiled .elc files (you will notice it in the debugger if you are running byte-compiled code) by entering commands like (load "foo.el") instead of (load "foo").
I got the same error when using find-grep after accidentally redefining (current-time-string) in one of my own scripts.
Using the M-x edebug-defun tip posted above I managed to find the issue when I stepped through the code giving the error seeing the call to (current-time-string).
Not sure how helpful this is in your case.