Based on How do you comment out all or part of a Lisp s-exp using Paredit? I did C-M-space then M-; and got, as expected, a commented-out S-exp:
;; (when window-system
;; (sr-speedbar-open))
Now how do I delete those semicolons? When I try the obvious (backspace or delete), only one semicolon disappears. I also can't just undo, since I've done other stuff between adding the semicolons and wanting to delete them. I could also turn off paredit for this task, but I'm certain there's a more elegant way.
One thing you could do is re-select the region and then do M-; again, which will un-comment the given region if it's already commented. You could also try this function that I've put together which deletes backwards on a given line, while still preserving delimiters (it's basically a backwards paredit-kill). You'd just navigate to the spot after the comment semicolons and then invoke paredit-backward-delete-line, preferably with whatever key binding that you bound it to (which was <C-backspace> in my above answer).
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.
Occasionally when I'm compiling, I have to scroll up my compilation buffer to see the details of an error. At this point, emacs stops "following" my compilation buffer, i.e., scrolling to automatically display new output.
I'm using Aqumacs on OS X. Any idea how I can "reattach" or re encourage the compilation buffer to follow again?
Regards,
Chris
Put in your ~/.emacs file
;; Compilation output
(setq compilation-scroll-output t)
or even
(setq compilation-scroll-output 'first-error)
to make it scroll to the first error.
Try using M-x auto-revert-tail-mode or M-x auto-revert-mode. Taken from official documentation:
One use of Auto-Revert mode is to
“tail” a file such as a system log, so
that changes made to that file by
other programs are continuously
displayed. To do this, just move the
point to the end of the buffer, and it
will stay there as the file contents
change. However, if you are sure that
the file will only change by growing
at the end, use Auto-Revert Tail mode
instead (auto-revert-tail-mode). It is
more efficient for this. Auto-Revert
Tail mode works also for remote files.
So, as Chmouel already noted, just moving point to end of buffer will also work.
I am not sure about aquamacs but for me (Emacs 23/Debian) I just go in the compilation window and place my cursor at the end of the window which will attach and follow (you can go to another window and it will still follow).
When editing an Rnw file in Emacs, I often want to make the region cover a chunk of text that contains an R chunk. For a simple example:
ewr
<<>>=
#
wer
I use transient-mark-mode such that the region is highlighted. But, if I put the point on the first line and hit C-SPC, then use C-n to move the point down, the highlighting disappears when I try to advance the point past the <<. The region I want is still selected, but highlighting seems to fail when crossing the <<. How can I fix this?
Thanks and best regards
I find that your problem shows up when I do what you describe, but it goes away if you scroll down using C-down or C-M-n instead. I think you can even use C-down to get past the R chunk and then C-n to step past lines afterward.
I had the same problem and the solution suggested by fojtasek did not work for me because I had an additional configuration problem. I hope that this might be useful for you and other users. Make sure that if you are using ESS and Auctex that you have fully loaded Auctex. To be more specific, it turned out that when I had previously installed auctex 11.86, I did not correctly load the package. Because I am a novice emacs user, I only managed to load the first of the following two lines:
(load "auctex.el" nil t t)
(load "preview-latex.el" nil t t)
If you have not added the second line, you will only have an Auctex menu but NOT a preview-latex menu.
Thanks to Fojtasek for the C advice. I find C- with the arrow key will keep a contiguous highlight. C-down brings up a page that says "this confusing feature has been disabled by default".
In my opinion, this behavior that OP complained about is a flaw in Auctex, and the fact that Fojtasek has a way to avoid it is helpful, but still it is just a workaround. I don't want Auctex to to this and I don't really want to have to use my left hand for holding down C while scrolling. PITA.
If Auctex needs some special selection tool, they should have to use unusual keystrokes for that. Why impose it on the rest of us who just want to highlight big sections and move them around, whether or not they have <<>> in them.
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.