After a long period of no development activity (mostly because it was perfect from the start), super-save gets an update today!

The latest 0.3 version of your favourite auto-saving library makes it easier to customize the hook triggers (see super-save-hook-triggers) and adds an option to ignore remote (TRAMP) files (see super-save-remote-files).

As a refresher - super-save will save modified files automatically on certain command (e.g. switch-to-buffer) and hook triggers (e.g. focus-out-hook).

Both of those are configurable via super-save-triggers and (starting with 0.3) super-save-hook-triggers. Here are a couple of examples:

1
2
3
4
5

;; add integration with ace-window
(add-to-list 'super-save-triggers 'ace-window)

;; save on find-file
(add-to-list 'super-save-hook-triggers 'find-file-hook)

You can now turn off super-save for remote files like this:

1

(setq super-save-remote-files nil)

It seems that now super-save is beyond perfect, so don’t expect the next release any time soon! ;-)

P.S. super-save was extracted from Prelude, but for some reason I actually forgot to add it to Prelude. Today that changes as well! :-)

For a while one of the biggest complaints people had about Projectile was that the alien indexing wasn’t fast enough (especially on big projects). The reason for the (relatively) bad performance was pretty simple - even though Projectile would normally obtain the list of project files pretty fast (e.g. by using git ls-files) it always did some post-processing of the results (e.g. filtering, sorting, etc), which is a very slow operation in Elisp on a big dataset.

Today I’ve added a new indexing method that simply dispenses with all of the post-processing and gives you the raw power you always craved for. It’s called turbo-alien (yeah, yeah - naming is hard!) and it’s going to be the default indexing method going forward (starting with Projectile 1.1 which should be released pretty soon).

You can read a bit more about it in Projectile’s manual.

If you find yourself missing Projectile’s old behaviour just add the following to your config:

1

(setq projectile-indexing-method 'alien)

The old tried and true alien method is still around, it’s just no longer the default.

P.S. I encourage all of you to help out with some of the open tickets marked with “Help Wanted” or “Good First Issue” here. I’m trying to clean-up shop after a long period of stagnation and I can certainly use some help! :-)

P.P.S. The recent 1.0 release was just a precursor to some bigger changes I had planned to do for quite a while. Stay tuned for more updates!

Back in 2013 I wrote about my favourite productivity boost in Emacs, namely remapping Return to Control, which in combination with the classic remapping of CapsLock to Control makes it really easy to get a grip on Emacs’s obsession with the Control key.

In the original article I suggested to OS X (now macOS) users the tool KeyRemap4MacBook, which was eventually renamed to Karabiner. Unfortunately this tool stopped working in macOS Sierra, due to some internal kernel architecture changes.

That was pretty painful for me as it meant that on my old MacBook I couldn’t upgrade to the newest macOS editions and on my new MacBook I couldn’t type properly in Emacs (as it came with Sierra pre-installed)… Bummer!

Fortunately 2 years later this is finally solved - the Karabiner team rewrote Karabiner from scratch for newer macOS releases and recently added my dream feature to the new Karabiner Elements. Unlike in the past though, this remapping is not actually bundled with Karabiner by default, so you have to download and enable it manually from here.

That’s actually even better than what I had originally suggested, as here it’s also suggested to use CapsLock with a dual purpose as well - Control when held down and Escape otherwise. I have no idea how this never came to my mind, but it’s truly epic! A crazy productivity boost just got even crazier!

Enjoy!

CIDER is a popular Clojure programming environment for Emacs.

In a nutshell - CIDER extends Emacs with support for interactive programming in Clojure. The features are centered around cider-mode, an Emacs minor-mode that complements clojure-mode. While clojure-mode supports editing Clojure source files, cider-mode adds support for interacting with a running Clojure process for compilation, debugging, definition and documentation lookup, running tests and so on.

You can safely think of CIDER as SLIME (a legendary Common Lisp programming environment) for Clojure - after all SLIME was the principle inspiration for CIDER to begin with. If you’re interested in some historical background you can check out my talk on the subject The Evolution of the Emacs tooling for Clojure.

Many people who are new to Lisps (and Emacs) really struggle with the concept of “interactive programming” and are often asking what’s the easiest (and fastest) way to “grok” (understand) it.

While CIDER has an extensive manual and a section on interactive programming there, it seems for most people that’s not enough to get a clear understanding of interactive programming fundamentals and appreciate its advantages.

I always felt what CIDER needed were more video tutorials on the subject, but for one reason or another I never found the time to produce any. In the past this amazing intro to SLIME really changed my perception of SLIME and got me from 0 to 80 in like one hour. I wanted to do the same for CIDER users! And I accidentally did this in a way last year - at a FP conference I was attending to present CIDER, one of the speakers dropped out, and I was invited to fill in for them with a hands-on session on CIDER. It was officially named Deep Dive into CIDER, but probably “Intro to CIDER” would have been a more appropriate name, and it’s likely the best video introduction to CIDER around today. It’s certainly not my finest piece of work, and I definitely have to revisit the idea for proper high-quality tutorials in the future, but it’s better than nothing. I hope at least some of you would find it useful!

You might also find some of the additional CIDER resources mentioned in the manual helpful.

Enjoy!

In Emacs you can evaluate Emacs Lisp pretty much anywhere - even in the minibuffer. Writing Emacs Lisp in the minibuffer, however, is not exactly fantastic experience out-of-the-box - there’s TAB completion, but what about eldoc and paredit for instance?

If only there was a way to enable them… I suggested one trick in my original post on eval-expression, but Emacs 24.4 made things even easier by adding eval-expression-minibuffer-setup-hook. To enable eldoc for minibuffer evaluations use this snippet:

1

(add-hook 'eval-expression-minibuffer-setup-hook #'eldoc-mode)

For paredit you can use this one:

1

(add-hook 'eval-expression-minibuffer-setup-hook #'paredit-mode)

Obviously you can do the same for any other minor mode you might need.

The best thing about this setup is that it will work with tools like CIDER and SLIME as well (they have similar commands which allow you to evaluate Clojure & Common Lisp code and those command trigger eval-expression-minibuffer-setup-hook).

If you know the name of some command, but you’ve forgotten its keybinding(s) there are 3 common options to look the keybinding(s) up.

• C-h f command-name

This will display some information about the command in question in a help buffer. Important bits of this information include where is the command defined, what are its keybindingings if any, and its documentation.

• C-h w command-name

This will display the keybindings of the command in the minibuffer. If you’re interested only in the keybindings you should prefer this option over C-h f.

• M-x command-name

After you invoke some command using M-x you’ll see a suggestion to use its keybinding instead in the minibuffer.

That’s all for now, folks!

By default Emacs has some pretty annoying audio notifications for certain events (e.g. trying to move past the end of a buffer). You’ve got two options to get rid of them. Option 1 is to replace them with visual notifications (the Emacs frame will flash):

1

(setq visible-bell t)

This doesn’t work well on OS X and is just as annoying (if not even more), so I’d suggest going with option 2 instead - disable those notifications completely:

1

(setq ring-bell-function 'ignore)

At last - some peace and quiet!

One of the things I hate the most while programming, is having to manually adjust the indentation of some code, after I’ve moved or renamed something in it. While it’s pretty easy to do such re-indent operations using commands like crux-indent-defun or advices like crux-with-region-or-buffer (you remember, crux, right?), there’s an even more efficient way to tackle the issue at hand. Enter aggressive-indent-mode.

aggressive-indent-mode’s name is a bit of a misnomer - it should probably have been named auto-indent-mode, as this is what it does. When you edit your code it will adjust the indentation automatically. It’s easier to show this than to explain it.

Here’s one example showing agressive-indent-mode enabled in emacs-lisp-mode:

And another example using cc-mode:

Provided you’ve installed the mode, enabling it for particular major modes is a piece of cake:

1
2
3

(add-hook 'emacs-lisp-mode-hook #'aggressive-indent-mode)
(add-hook 'clojure-mode-hook #'aggressive-indent-mode)
(add-hook 'ruby-mode-hook #'aggressive-indent-mode)

If you want to enable it in all major modes you can do this as well:

1

(global-aggressive-indent-mode 1)

Note that this is not going to work well with modes like python-mode and haml-mode where the proper indentation can’t be reliably determined. When global-aggressive-indent-mode is enabled it will not affect major modes listed in aggressive-indent-excluded-modes.

For more info - head over to the project’s readme.

If you ever need to show the keybinding for a particular command to the users of your package (e.g. you’re adding some tips functionality), you should avoid resisting the urge to write something like this:

1

(message "Press <C-c p p> to switch between projects.")

Why is this a bad idea? Because you might change the keybinding of the command in question (e.g. projectile-switch-project, but you might forget to update messages like this. Is there a better way? substitute-command-keys to the rescue:

1

(message (substitute-command-keys "Press <\\[projectile-switch-project]> to switch between projects"))

This will produce exactly the same message as before and you’re guaranteed the keybinding will always be in sync with the command.

Neat!

P.S. If you want to check interactively the keybinding of some command use C-h f (describe-function). Here’s an example - C-h f RET projectile-switch-project RET will produce this:

1
2
3
4
5
6
7
8

projectile-switch-project is an interactive compiled Lisp function.

It is bound to C-c p p, s-p p, <menu-bar> <tools> <Projectile> <Switch
to project>.

(projectile-switch-project &optional ARG1)

...

You can also check which command is bound to some key with C-h k.

By default in Emacs the Tab key does only indentation. If some major mode provides completion of some form, you normally have to trigger it with M-Tab. In most window managers, however, this keybinding is used to switch between open windows, which makes it a bit hard to use out of the box.

There’s a simple trick to augment the default Tab behavior. Just put this in your Emacs config:

1

(setq tab-always-indent ‘complete)

Now, when you press Tab one time it will indent and if you press it again you’ll get completion candidates. If the indentation at point is already correct you’ll get the completion candidates right away. As an added bonus - you don’t really need M-Tab anymore.

Simple and neat! One really has to wonder why this isn’t the default behavior.