Pretty much every Emacs user knows of the *scratch* buffer - after
all it’s always present when you start your Emacs. If you’ve set
inhibit-startup-screen to t (which I recommend) it will even be
the very first buffer see each time you fire up your beloved editor
(unless you alter initial-buffer-choice, that is).
The scratch buffer was conceived a scratchpad for notes and Emacs Lisp
experiments and a lot of Emacs users find it quite handy. On the
other hand - even more users don’t really write Emacs Lisp and
probably find little value in this buffer.
One little know fact about the *scratch* buffer is that its initial
major mode (by default it’s lisp-interaction-mode) is not hardcoded
and you can alter it. If you’re a Ruby developer you might opt to
make it use ruby-mode by default:
If you do this I’d also advise you to change the buffer’s initial
contents. By default they are:
;; This buffer is for notes you don't want to save, and for Lisp evaluation.;; If you want to create a file, visit that file with C-x C-f,;; then enter the text in that file's own buffer.
For Ruby something like this might be better:
(setqinitial-scratch-message"\# This buffer is for notes you don't want to save, and for Ruby code.# If you want to create a file, visit that file with C-x C-f,# then enter the text in that file's own buffer.")
Or you can simply set initial-scratch-message to nil and be done with it.
Securing funding for OS projects and blogs (outside of displaying annoying ads)
is a hard endeavor. While I’d love to raise enough cash to work on
CIDER, projectile and Emacs itself for an entire year through some
wildly successful crowdfunding campaign, that’s unlikely to ever
That said, I recently discovered an interesting alternative to one-off
crowdfunding campaigns called gittip.
Self-described as sustainable crowdfunding (meaning people will get
microdonations (say half a buck) from their patrons each week) it seems like a
reasonable way to raise a modest sum of money so you could work on
open-source projects more than your regular schedule might permit.
So, if you like Emacs Redux and the Emacs projects in which I’m involved like:
Prelude - An Emacs distribution built on top of GNU Emacs 24
Projectile - Project Interaction Library for Emacs, that stays out of your way
The problem with Emacs blogs is one can never have enough of them (especially the good ones).
I’d like to draw my readers attention to two new blogs:
lunarsite is not exactly new (it was
started in March 2014), but I don’t think enough people have come
across it, so I’m mentioning it here anyway. It’s operated by one of
the most prolific members of the Emacs community in recent years - the
great Sebastian Wiesner
(of flycheck and cask fame).
If you’re thinking of writing your first major mode - you’ll find some
great advice there.
One thing Emacs users deal all the time is looking for the source of
various libraries and function or variable definitions. Typically this
involves the use of commands like C-h f (describe-function), C-h v
(describe-variable) and C-h k (describe-key) and jumping to the source from the help buffer those commands produce.
Let’s see if we can improve upon this workflow.
Enter the built-in Emacs library find-func. It provides a myriad of useful commands to help us quickly locate sources.
Let’s take a brief look at some of them.
You can find the source of a library with M-x find-library. If you want to find the source of ido you can do so like this:
M-x find-library RET ido RET
I’d suggest binding the command to C-h C-l for quick access:
You can find the source of a function definition with M-x find-function. Here’s an example:
I’d suggest binding the command to C-h C-f for quick access:
We can actually do one better - we can directly jump to a command
definition using a keybinding of the command with M-x
find-function-on-key. Here’s how we can find the source the command
bound to C-a (beginning-of-line):
I’d suggest binding the command to C-h C-k for quick access:
I’d suggest binding the command to C-h C-v for quick access:
The library provides other useful commands as well - like
find-function-at-point and find-variable-at-point.
If you don’t like the keybindings I suggested you can use
find-function-setup-keys instead. This will give you keybindings
like C-x F, C-x V, C-f K (plus a few extra for commands like
Another really cool way to browse Elisp sources (and documentation) is the third-party package
elisp-slime-nav. Assuming you’ve installed it already you can
enabled it like this:
Once this is done you’ll be able to jump to the source of the Emacs
Lisp object at point (function or variable) with M-. (as in SLIME
and CIDER for Common Lisp and Clojure respectively) and jump back with
M-,. You can also see the description of the object at point using
C-c C-d (or C-c C-d d).
That’s all for today, folks!
All the suggested keybindings are present out-of-the-box in
Prelude. elisp-slime-nav is also
enabled out-of-the box in Prelude.
We all know and love the
MELPA package repository. At least we
all know it, but not everyone loves the idea of using package
snapshots. Some people would rather use only stable package
releases and that’s understandable. Unfortunately the major community
repository for stable packages Marmalade
is often plagued by technical issues (that should be fixed once its
elnode-powered rewrite is ready) and stale packages (due to the fact
the sometimes people upload packages they don’t own there and stop
updating them after a while).
Now there’s an alternative to Marmalade, which offers a MELPA-like
experience - MELPA stable. It
offers stable packages built automatically from git tags, meaning
the only thing you have to do to release a new version of a package
(assuming there’s a MELPA recipe for it, of course) is to tag the release in
git. No more stale packages! No more manual package uploads!
To use the new repo add this to your Emacs config:
Currently more than 500 packages are available for installation there.
That number is bound to grow (a lot).
By the way, the maintainers of MELPA are looking for help to update
the home page of the stable package archive. Currently it’s the same
as the one of the snapshot archive, which is a bit confusing
(especially regarding installation instructions). If you’d like to
help fork and improve the
page’s code on GitHub.
I guess everyone has seen the following warning (at some point or
another) when trying to open a relatively large file in Emacs:
File foo.bar is large (XX.XM), really open?
By default Emacs will display this warning for every file bigger than
10MB, which is quite annoying (conservative), especially given the
fact that on any modern computer even much bigger files will be loaded
almost instantaneously and won’t slow down Emacs significantly.
You can adjust this behavior by altering the value of the
large-file-warning-threshold variable. I’d suggest setting it to
something like 100MB:
;; warn when opening files bigger than 100MB(setqlarge-file-warning-threshold100000000)
Alternative, you can set it to nil, which will suppress the
warning permanently, regardless of the size of the file you’re trying to open.
P.S. By the way, it’s not particularly wise to edit huge files
(say bigger than 1GB) in Emacs directly. If you need to do something
like this I’d suggest taking a look at the excellent
Every developer is sometimes in the following situation - you’re
inside the definition of something like a class or method, but the
name of the class or method is not currently into view, but you’d very
much like to know/see it. You can obviously scroll up and see what you
need to, but there’s a simpler way to see the name you’re looking
for - the built-in mode which-function-mode.
When which-function-mode is active you’ll see in the center of your
modeline the name of the definition your cursor is currently in.
Here’s the mode in action:
And here’s how to enable it:
That way which-function-mode will be active in all major modes that
support it. If you want to enable it only in specific modes you can do
so like this:
By default ??? will be displayed when which-function-mode cannot
determine the name (perhaps because you’re not actually in a
definition or due to implementation limitations). You can change this
to something else like this:
And what if you don’t like to have the definition name displayed in
the mode-line? There’s a solution for you as well (suggested by
Sebastian Wiesner). Use the following bit
;; Show the current function name in the header line(which-function-mode)(setq-defaultheader-line-format'((which-func-mode(""which-func-format" "))))(setqmode-line-misc-info;; We remove Which Function Mode from the mode line, because it's mostly;; invisible here anyway.(assq-delete-all'which-func-modemode-line-misc-info))
And you’ll get the following result:
That’s all for today, folks! Hack Emacs Lisp & prosper!
In most Lisps numeric comparison functions like =, <, >, <=
and >= are variadic - meaning they accept variable number of arguments (as do functions like +, -, *, etc).
Here’s an example:
;; let's assume that all those are numeric variables(=xyz)(<abcd)
This is pretty cool and save you from writing code like:
Prefix function position for the win!
In Emacs Lisp, however, all these comparison functions (unlike +, -, etc)
accept just two arguments, which is somewhat unlispy. Luckily this is
one of the things that’s going to change with Emacs 24.4.
Emacs Lisp takes another small step to becoming a good Lisp dialect!