People often ask how am I navigating efficiently Emacs windows and
buffers. I have the feeling they expect me to share with them some
secrets that would turbo-charge common commands like C-s, M-f,
C-x o, etc. I don’t, however, use those commands that much. Ever
since I saw that vim’s
EasyMotion has been
ported to Emacs, I’ve been using that port - namely
Basically, it allows you to navigate to every visible portion of your
Emacs (buffers & windows) with only a handful of keystrokes (usually
one two activate it and one or two to get where you want to go). You
can see it in action in this
excellent video. ace-jump served
me well for years, but I’ve had a few gripes with it that were never
addressed (multi-char targets, CamelCase support, etc). I would have
implemented those myself, if the project was maintained at all, but
alas - that’s not the case. Seems I wasn’t the only one who was
frustrated with ace-jump, as the prolific
Oleh Krehel reimplemented it pretty much from
scratch for the purposes of his excellent
ace-window library. Once I
got wind of this, I managed to persuade Oleh to start distributing his
rewrite as a standalone project, which he dubbed
Avy features everything ace-jump does and more. Apart from the
many extra features, its codebase is way cleaner and readable and Oleh
is a fantastic and very responsive maintainer. So, as far as I’m
concerned ace-jump is now a dead project and pretty much everyone
who’s using it should try out avy instead. Their usage and interface
are pretty similar, so the learning curve is non-existing. By the way,
here’s avy in action:
And what about my usage of avy? Nothing fancy here - I just bind the
commands I consider most important to handy keystrokes.
avy-goto-word-or-subword-1 is aware of CamelCase words and I do a
lot of programming in languages that use those extensively.
avy has one more thing going for it - it’s part of the default Emacs
package repo GNU ELPA, which means
that you can install it right away without having to setup any
third-party repositories (which you’ll probably need sooner or later).
JDEE (Java Development
Environment for Emacs) used to be best way to develop Java apps in
Emacs a while back. It offered a ton of
like smart auto-completion and a debugger. Unfortunately at some point
the development slowed down significantly and the project went in a
catatonic state. There was pretty much no activity for years in the
official SourceForge repo and there was also no support for features
introduced in Java 5+.
Recently, however, the project migrated to
GitHub and it’s now way easier
to get involved. Seems that some people have already started work on
updating JDEE to support modern JDKs and modern Emacs functionality.
That’s a really exciting project, as Java support has traditionally
been a weakness of Emacs and I’m writing this post with the hope that
more people will help make JDEE great again.
So what are you waiting for? If you’re into Java and friends (Scala,
Clojure, Groovy, etc), check out the new official repo and let’s get
this party started!
People who have been using Emacs for a while often develop the desire
to learn Emacs Lisp, so they can customize Emacs more extensively,
develop extra packages and create the ultimate editing experience,
uniquely tailored to their needs & preferences.
There are a ton of Emacs Lisp resources our there, but most people
generally need only one - the official
Emacs Lisp manual. It’s
bundled with Emacs and you can start reading right away by pressing
C-h i m Elisp RET. If you’re relatively new to programming in
general you might also check out the
Introduction to Emacs Lisp
(C-h i m Emacs Lisp Intro RET), before diving into the manual.
There are also plenty of Emacs Lisp tutorials online, but I’d advise
against using them, as most of them have never been updated after
originally published and Emacs Lisp keeps evolving all the time
(albeit not as fast as I would have liked it to). That being said,
Learn Emacs Lisp in 15 minutes
is a short and sweet intro to the language. You can find more online
educational resources on the
Trust me on this - any time invested in learning Emacs Lisp will be
time well spent!
In this article I’ll share with you a few tips and tricks about
running Emacs under the Max OS X operating system. This article will
focus on the vanilla GNU Emacs, but if you want a more native OS X experience you
might have a look at the
enhanced Emacs Mac port.
I always run the latest development version and I use homebrew to install it:
$ brew install emacs --HEAD --with-cocoa
Keep in mind there’s an ancient Emacs 22 that ships with OS X. You
might want to alter your PATH, so that the new Emacs is picked up in
Alternatively you can just create an alias in your shell and when you
invoke emacs it will run the newly installed version:
$ alias emacs="/Applications/Emacs.app/Contents/MacOS/Emacs -nw"
If you installed via Homebrew that path might look like this:
$ alias emacs="/usr/local/Cellar/emacs/24.5/Emacs.app/Contents/MacOS/Emacs -nw"
To make it permanent, if using bash, add that line to
~/.bash_profile. zsh users will want to update ~/.zshrc instead.
In case you’re wondering - nw tells Emacs to start in “terminal”
mode (instead of in GUI mode).
I heartily recommend you to remap your Caps Lock key to Control. This
can be easily done via Preferences -> Keyboard -> Modifier Keys. If
you’re using a laptop keyboard or the bluetooth keyboard you
might want to remap your right Option key to Control as
well. No one can use effectively Emacs without a right Control
key. Remapping it is a bit more involved and requires the use of the
Long story short - if you’re running Emacs from Spotlight (or any
other launcher for that matter) your PATH and exec-path variables
won’t be same as the ones in your shell (and that’s every nasty since
you want be able to run some external programs from Emacs). The best
way to handle this would be installing the package
by Steve Purcell.
For flyspell to work correctly you’ll need to install aspell plus a few dictionaries.
$ brew install aspell --lang=en
doesn’t work on OS X. You can use
as a replacement. It’s kind of basic, but it mostly works.
OS X ships with BSD’s ls command which doesn’t have all the features
of GNU ls (used internally by dired). Fortunately, this is easily solvable:
$ brew install coreutils
To avoid conflicts the GNU utils are prefixed with g, so ls becomes gls.
Dash is the ultimately API documentation
browser. I can’t live without it!
If you’re using it as well, you might want to install
If you want to spare yourself part of the headache of configuring
Emacs on OSX and get a lot of extra firepower you might want to install
Emacs Prelude - an enhanced
Emacs 24.x configuration (developed by yours truly) that should make
your experience with Emacs both more pleasant and more powerful.
P.S. I’d like to hear your tips & suggestions about making the
Emacs experience on OS X nicer and more powerful!
comint provides Emacs infrastructure for building command
interpreters. It’s backing a lot of popular shell/REPL modes - like eshell,
inferior-lisp, inf-ruby, inf-clojure, etc.
comint provides a myriad of built-in commands, but somewhat surprisingly
it doesn’t feature a command to clear the contents of a comint buffer.
Let’s write one such command ourselves!
While there are several way to tackle it, I feel this is the simplest
(and the one that makes the best use of comint’s existing
(defuncomint-clear-buffer()(interactive)(let((comint-buffer-maximum-size0))(comint-truncate-buffer)));; let's bind the new command to a keycombo(define-keycomint-mode-map"\C-c\M-o"#'comint-clear-buffer)
Simple and elegant, right? One day it might even end up being part of comint itself.
On graphical displays, each Emacs window normally has narrow fringes (gutters/margins)
on the left and right edges. The fringes are used to display symbols
that provide information about the text in the window. You can type
M-x fringe-mode to disable the fringes, or modify their width. This
command affects fringes in all frames; to modify fringes on the
selected frame only, use M-x set-fringe-style. You can make your
changes to the fringes permanent by customizing the variable
Out-of-the-box the most common use of the fringes is to indicate a continuation
line. When one line of text is split into multiple screen lines, the
left fringe shows a curving arrow for each screen line except the
first, indicating that “this is not the real beginning”. The right
fringe shows a curving arrow for each screen line except the last,
indicating that “this is not the real end”. If the line’s direction is
right-to-left, the meanings of the curving
arrows in the fringes are swapped.
Third-party modes like
diff-hl also make use of the fringe to
display valuable information there (e.g. lint and VC information).
By default both fringes have width 8 pixels, but we can easily adjust this:
;; make both fringes 4 pixels wide(fringe-mode4);; make the left fringe 4 pixels wide and the right disappear(fringe-mode'(4.0));; restore the default sizes(fringe-modenil)
As mentioned before, you can also invoke this command interactively and
determine the optimal fringe size for you, before making it permanent in
your config. The options presented by the fring-mode command are defined
in the fringe-styles list:
(defconstfringe-styles'(("default".nil)("no-fringes".0)("right-only".(0.nil))("left-only".(nil.0))("half-width".(4.4))("minimal".(1.1)))"Alist mapping fringe mode names to fringe widths.Each list element has the form (NAME . WIDTH), where NAME is amnemonic fringe mode name and WIDTH is one of the following:- nil, which means the default width (8 pixels).- a cons cell (LEFT . RIGHT), where LEFT and RIGHT are respectively the left and right fringe widths in pixels, or nil (meaning the default width).- a single integer, which specifies the pixel widths of bothfringes.")
Be careful when playing with the fringe size. Certain info doesn’t
look very good when the fringe is too small (e.g. less than 4 pixels).