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've been fooling around with comint-mode lately and I'm noticing some weird behaviors. Its very poorly documented, so I'm wondering if anyone has any insight on this.
In some modes, comint-send-string causes whatever is sent to be inserted into the comint buffer and then sent to the associated process, whereas in others, the input is send directly to the process without being placed into the buffer. For example, do run-python with the new (24.3) python.el and then do (comint-send-string "*Python*" "x=3\n"), the string x=3 is inserted into the buffer and then executed. If you do M-x shell, however, and then (comint-send-string "*shell*" "x=3\n"), no text is inserted into the buffer, the input is simply sent to the shell process directly to be executed.
Does anyone know why this difference in behavior exists or how I can change it?
I observe identical behavior on linux (emacs-version == "24.3.50.7", both GUI and emacs -Q -nw): neither
(comint-send-string "*Python*" "x=3\n")
nor
(comint-send-string "*shell*" "x=3\n")
insert anything in the comint buffer (i.e., the next prompt appears
right after the previous prompt - without even a newline between them).
I eventually figured it out. For some reason the system python on OSX causes this behavior, installing python from homebrew fixed it.
I am using emacs and the auto-newline feature is not working as expected. I have a pretty large number of customizations done to my emacs. So it would be no wonder if one of the other customizations is not what auto-line is expecting. I would like to know if there is a way to know the list of commands (list of emacs commands) executed by emacs at a particular point, for e.g. when ctrl-s ctrl-c or in my case when auto-line feature is called.
edit : I think you have misunderstood the question. I would like to know what command emacs calls 'internally'.
I believe view-lossage is what you're looking for -- M-x view-lossage, or C-h l.
If you want to know what a keystroke is bound to, consider using describe-key, which is usually bound to C-h k.
Basically at this point, you need to bite the bullet and learn some Emacs-lisp. The debugger is what you are looking for to dig further into your problem (I use edebug). It's not just about seeing what functions get called, you also need to see the values of the relevant variables when those functions are called.
If you feel you're not up to it, then you can bi-sect your init file until you find the culprit, but at that point you still need some Emacs-lisp to investigate further.
To add to what #event_jr said --
What you seem to be asking is the history of the functions called by the command you last invoked. (You speak of Emacs "internal commands", but it seems you just mean functions.)
To get that history for any given command you invoke (e.g., by a key), use M-x debug-on-entry and then enter the command name. The next time you use that command, you can walk through its execution in the Emacs debugger (hit d to step, c to continue past a step).
I am using run-octave in Emacs to trigger octave. Something is acting abnormally.
Every time I hit TAB to complete, there would be a tailing ^M; If I edit a .m file using edit a.m, it would start a new frame instead of a new buffer and the prompt is waiting for the closure of that frame so it would not respond to any input. How could I configure .emacs so that run-octave would behave normally?
Any comment is appreciated!
You seem to have two problems. I'm not sure about the trailing ^M, which seems to be caused by some sort of Windows/Unix CR/LF problem, but maybe I can help with the second problem.
The edit command uses the EDITOR environment variable to decide what to run. It seems that yours is either set to emacsclient or has defaulted to it. You haven't said whether you're on Unix or Windows, so I'm going to assume the former: you'll have to change this a bit for Windows.
To avoid the waiting thing, try running octave with a different EDITOR. For example, try out running
EDITOR='emacsclient -n' octave
When you type edit foo, it should bring up an Emacs buffer (if you want a new frame as well, use -c too) but not wait until you're done.
If this fixes things for you, you could change your ~/.bashrc to include the line
export EDITOR='emacsclient -n'
One of my colleagues uses TextPad, and one feature I found really useful is the Auto-Reload. (The feature has been described in this SO quesion: Alternative to TextPad's Prompt to Reload File). Basically, it keeps reloading the file without any prompt from the user, which is really helpful when monitoring log files that are updated in real-time. Is there something similar available for Emacs? If not, can anyone whip up the required elisp magic?
M-x auto-revert-mode
I should add that for log tails, there is the more specific auto-revert-tail-mode, and that if you like it as a general feature (my case), you can turn on global-auto-revert-mode, to revert all buffers. Beware of remote files in that case.
If you want auto-revert to apply everywhere you can also use global-auto-revert-mode. Add
(global-auto-revert-mode 1)
to your .emacs
Here's my preference, FWIW: I do not use auto-revert. Instead, I bind f5 to this command:
(defun revert-buffer-no-confirm ()
"Revert buffer without confirmation."
(interactive) (revert-buffer t t))
Sounds silly, but that simple change makes all of the difference. This is what f5 does anyway on MS Windows, so it's a habit that works in all applications (on Windows).
Note that I do not change (e.g. remap) any bindings for revert-buffer. I use this only when I explicitly want to revert without confirming (which is quite often, in practice).
HTH.