Here are some recent improvements I made to my Emacs startup. The full file with these changes is on GitHub.

Disable toolbar and menu at the beginning

Since there can be a noticeable delay while Emacs processes the init file, especially if it is downloading packages, it’s better to customize the GUI as early as possible to avoid the window jumping around. I also made monokai-theme the first package I require after use-package, although I think this has limited utility.

Add these lines to the beginning of ~/.emacs.d/init.el:

1
2
3
4

;; remove GUI stuff
(when (fboundp 'menu-bar-mode) (menu-bar-mode -1))
(when (fboundp 'tool-bar-mode) (tool-bar-mode -1))
(when (fboundp 'scroll-bar-mode) (scroll-bar-mode -1))

Don’t show GNU start screen

Get rid of the GNU splash/startup screen, and also remove the unnecessary message in the *scratch* buffer:

1
2
3

;; show blank *scratch* buffer at start
(setq inhibit-startup-screen t)
(setq initial-scratch-message nil)

Disable bell

I can’t really express just how much I hate the bell. I disable it in Vim, I once even went so far as to unhook the internal PC speaker from the motherboard of one machine. It’s often suggested to (setq visual-bell t), but that makes Emacs flash the window which is almost as annoying. Here’s how to disable it entirely (from this StackOverflow answer):

1
2

;; disable bell
(setq ring-bell-function 'ignore)

As I start to add more packages and customizations to my emacs configuration, it would be a good idea to have a plan for organizing things to keep it manageable. Funnily enough, there is a package called use-package that seems like it will be useful in this endeavor, so let’s use it.

First, you can read more about use-package at its Github repository, this reddit thread, or this blog post. The main advantages of use-package for my purposes are:

• the :ensure keyword automatically installs packages (replaces my ensure-package function)
• it helps centralize configuration related to each package
• it can defer executing code for packages which are only needed in certain modes

The last two are not such a concern yet, but will be useful in the future.

I have refactored the init.el file from before. You can see the new contents below (with comments), or just download the raw file.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

;; setup for requiring and installing packages

(require 'cl)
(require 'package)

;; add extra ELPA archives
(add-to-list 'package-archives
             '("melpa" . "http://melpa.milkbox.net/packages/") t)

;; initialize package system
(package-initialize)

;; get list of packages if not present
(unless package-archive-contents
  (package-refresh-contents))

;; make sure use-package is installed (we'll use it to install other packages)
(unless (package-installed-p 'use-package)
  (package-install 'use-package))

;; make use-package available
(require 'use-package)


;; set up individual packages

;; evil-mode
(use-package evil
  :ensure evil
  :config
  (progn (evil-mode 1)))

;; monokai theme
(use-package monokai-theme
  :ensure monokai-theme
  :config
  (progn (load-theme 'monokai t)))


;; set up interface customizations

;; keybindings:

(define-key key-translation-map [?\C-h] [?\C-?])
(global-set-key (kbd "M-h") 'help-command)

;; GUI settings:

(tool-bar-mode -1)
(menu-bar-mode -1)

I got rid of ensure-package and made some changes based on the Stack Overflow question here. It makes sense to me for updating packages to be manually invoked, so we can think of our process as: for a new system with no packages (and no package-archive-contents), we first fetch the list of packages, install use-package, and use use-package to install and configure our other packages; in normal use, our packages are already installed and use-package configures them. When we want to add a package, just add (use-package <package> ...) to our config file and let use-package install it for us.

For upgrading packages, it may make sense to have a function to do everything necessary (I haven’t looking into what that would be) that I can invoke in one step. Alternatively, I could just nuke ~/.emacs.d/elpa/ — (not-so-)instant upgrade!

So in the last post, we got Emacs working nicely with Vim keybindings using evil. But there is one keybinding that immediately started bugging me:

Emacs binds <Ctrl>-h to the help command. For example, you press <Ctrl>-h k and then press a key to get information on functions bound to that key; you press <Ctrl>-h f and enter a function name to get help on that function, etc.

Now I don’t know about you, but having basically lived in the terminal for years now, I am used to <Ctrl>-h sending a backspace character, which works in the shell and in Vim. And while help is undeniably useful (Vim’s help is really great, by the way), I’m not sure it should be bound to a key in the home row. So let’s fix that:

1
2

(define-key key-translation-map [?\C-h] [?\C-?])
(global-set-key (kbd "M-h") 'help-command)

Add these lines anywhere in ~/.emacs.d/init.el. I put them just above (tool-bar-mode -1).

And that’s it! You can happily use <Ctrl>-h to backspace to your heart’s content. If you do want to access Emac’s help, you can press <Alt>-h instead. By default, <Alt>-h is bound to mark-paragraph, which we don’t need because evil allows us to select a paragraph by pressing vip, just like in Vim.

You can read more at the Emacs Wiki, which is where I found the above lines.

So you’re a dyed-in-the-wool vimmer, but now you want to use Emacs? (Sorry, I meant I—I am a dyed-in-the-wool vimmer and I want to use Emacs.) Let us go on a journey together…

Reasons

Here are some reasons I can think of to use Emacs:

• to get used to Emacs, for instance to be able to work on systems that don’t have Vim installed (shudder)
• to make use of some Emacs plugin that doesn’t have a good substitute in Vim (e.g. org-mode)
• because Emacs GUI works better in Windows than GVim ¹
• because Emacs Lisp is nicer than Vimscript ²

A lot of my motivation has to do with my workflow, which is a mix of tmux and vim in the terminal. It works pretty well, especially with Tim Pope’s vim-tbone plugin, which gives you Tyank and Tput commands to communicate with the tmux copy buffer. However, I got curious what it would be like for the editor and shell to be more equal, which Emacs seems to offer.

“Why use Emacs in a terminal when you can use a terminal in Emacs?”

— Me

Preparation

Since you are like me, I’m assuming you don’t have any Emacs configuration files, no .emacs or .emacs.d/. I recommend creating a directory emacs.d/ (no leading ‘.’) in a git repository somewhere.³ You can then check out the repository on any system and symlink the emacs.d/ directory to ~/.emacs.d/ (with leading dot). You can look at my dotfiles repo for reference if you like.

Anyway, now inside the emacs.d/ directory create a file named init.el. Emacs will read the file at ~/.emacs.d/init.el during startup; we will be putting all of our customizations inside this file for now. Before we put anything into init.el, you can try starting up Emacs to see what it’s like. To move around, <Ctrl>-p and <Ctrl>-n move up and down, and <Ctrl>-f and <Ctrl>-b move forward and backward. To quit press <Ctrl>-x <Ctrl>-c (that is, hold down <Ctrl> and press x and then c).

Since Emacs is modeless, hjkl and other printable characters always insert themselves, and thus to execute commands you have to use modifier keys. <Ctrl> is okay, since you should have CAPS LOCK mapped to Control ⁴ (or for Windows), but Emacs makes you press the Alt key, which I am not going to put up with, so we’ll be using an Emacs plugin called ‘evil’ to make Emacs more like Vim.

Onward!

Don’t worry, I won’t make you edit your init.el from inside Emacs (you can try it if you want to, but you’ll need to quit and restart Emacs every time you change it), so let’s just open it inside Vim:

1

$ vim ~/.emacs.d/init.el

and add the following lines:

1
2
3
4
5

(require 'cl)
(require 'package)

(add-to-list 'package-archives
             '("melpa" . "http://melpa.milkbox.net/packages/") t)

The default Emacs package repository at http://elpa.gnu.org/ contains a limited set of packages, and most importantly for our purposes does not contain evil, so we are adding the MELPA repository, which does have evil, along with a lot of other packages. The first two lines import the cl package and the package package. The package package imports things related to packages (duh), like the package-archives variable or the package-install function we will use shortly. The cl package is the Common Lisp compatibility package; I’m not actually sure of everything it does, but some things seem to need it and it’s probably just easiest to add it in at the very beginning.

At this point, you can start up Emacs, and from the ‘Options’ menu choose ‘Manage Emacs Packages’. You should see a list of packages, and if you scroll down a bit, you should find the ‘evil’ package listed, along with some evil plugin packages like ‘evil-leader’. Try clicking on the blue ‘evil’ link. A window split should open up with the bottom half showing details for the ‘evil’ package. There is an Install button that you can press to install the package; alternatively, you can (in the top window) press i on the ‘evil’ package line to mark it for install and then press x to install it. Either way, some messages will flash by in the bottom window about compiling whatever, possibly some warnings which you can ignore (I do), and then evil will be installed! Great!

Of course, nothing changes because it isn’t activated automatically. First, click in the top window (with the package list), type <Ctrl>-x 1 to close the bottom window (if you opened it), and type q to quit the package manager interface. You should return to the ‘GNU Emacs’ start screen. Open up the scratch buffer by going to the ‘Buffer’ menu and selecting ‘*scratch*’. Emacs automatically creates this *scratch* buffer every time you run it and the contents are not saved when Emacs quits. It’s useful for typing stuff, which is what we’re going to do. First try typing something and see that everything is still just like it was, typing letters inserts them and the <Ctrl>- keys move around.

Now, type <Alt>-x (the only time I’ll ask you to press the Alt key, I swear!) and at the prompt (in the minibuffer at the bottom of the screen) type evil-mode and hit Enter. What changed? Try typing k.

!

The cursor should have moved up a line! If you look at the mode line (the status line at the bottom of the window) you should see <N>. That indicates that you’re in the evil normal state. In evil, states are the equivalent of Vim’s modes, because Emacs already uses the word ‘mode’ for something more like Vim’s ‘filetype’. If you type i or a you will enter insert state (Vim’s insert mode). At this point you can just start doing whatever you would do in Vim. Some things won’t work, a few things will be slightly different, but mostly things will work in evil just as they do in Vim—including things that don’t work in vi, because evil is a Vim mode for Emacs, not a vi mode.

Ex (colon) commands work as well, which I understand is a fairly recent change. You can type :ls<Enter> and the Emacs ‘Buffer List’ buffer will come up. You can hit q here to close the buffer list and return to the scratch buffer, because evil leaves some keybindings alone in some Emacs modes. Unfortunately, you can’t hit Enter to open up a buffer⁵—it just moves down a line. This is a good place to use another evil feature: by default, the \ key escapes one key press to execute the original Emacs command bound to that key; if you hit \ and then Enter, it should open the buffer you selected.

Leveling Up

This is all well and good, but currently every time you start Emacs you will have to type <Alt>-x evil-mode <Enter>—the horror! So let’s close Emacs and go back to our Vim where we have init.el open. Add these two lines to the end:

1
2
3

(package-initialize)

(evil-mode t)

Emacs actually calls package-initialize automatically, but only after it loads init.el, and we need it to use things in packages, so we call it ourselves. The last line activates evil, so that every time we start Emacs, it will start in evil mode. Try it: (re-)start Emacs, see that the mode line shows <N> and you can move around with hjkl, go to the *scratch* buffer (try :b<Space>scr<Tab> and hit Enter), type– whatever, you know what you’re doing by now.

Going Further

So this is great, again, but what happens when you move to a different system, or reinstall your OS? You’d have to install evil manually again. Wait—I know what you’re going to say, and I have the answer:

1
2
3
4
5
6

(defun ensure-package (package)
    (unless (package-installed-p package)
      (package-refresh-contents)
      (package-install package)))

(ensure-package 'evil)

Put these lines after (package-initialize) and before (evil-mode t), then to test run rm -rf ~/.emacs.d/elpa in your shell (.emacs.d/elpa/ is the directory where Emacs keeps the packages it installs) and restart Emacs. You should see Emacs downloading and installing evil in a split window. Unfortunately it leaves the compilation log buffer open in the bottom window, which you can close by typing <Ctrl>-w o in the top window. (I don’t have a solution for this yet, sorry).

Extra Credit

Lose the Toolbar and Menu

Do you like that toolbar that takes up like 5% of the screen? Do you want to be constantly reaching for the mouse to dig through a bunch of menus? (A: No!)

That’s what I thought. Put these lines at the end of your init.el:

1
2

(tool-bar-mode -1)
(menu-bar-mode -1)

Restart Emacs, and— ahh! Much better! You can never have too much screen real-estate. If you do want to show the menu temporarily, just type :menu-bar-mode to toggle the menu on and off.

Colors!

Okay, it has colors, but do we really think the default color scheme is the best we can do? Personally, I suggest the monokai theme, for which we can install a package from MELPA. Now, we could just add (ensure-package 'monokai) to the init.el file, but I think we can do better. Delete the (ensure-package 'evil) line and add the following:

1
2
3
4
5
6

(setq packages '(
                 evil
                 monokai-theme
                 ))

(mapcar 'ensure-package packages)

If you’re not familiar with Lisp, (setq x '(…)) sets the value of variable x to whatever the other argument is, in this case a quoted list. (mapcar 'f x) applies the function named f to each member of list x. In other words, we call ensure-package on every package named in packages. For just two packages, this is more work than necessary, but as you want to add more packages, all you need to do is add the package name to the list, and it will be installed next time you start Emacs!

Of course, just installing the package doesn’t cut it, so add (load-theme 'monokai t) to the end of your init.el (you can put it anywhere, actually, I just think it feels right as the last thing in the file).

If you don’t like Monokai, you can try Solarized for Emacs (add color-theme-solarized to packages and (load-theme 'solarized-[light|dark] t) instead of (load-theme 'monokai t)).

tl;dr

Download the file at https://gist.github.com/cordarei/9600170 to ~/.emacs.d/init.el, start Emacs, and enjoy Vim keybindings in Emacs!

Follow these steps to create a blog using Octopress on GitHub. I’m assuming you have a system ruby installed; preferably you’re using Arch Linux, because that’s what I used.

1. First — don’t read the documentation on github.com

Don’t bother reading the help documents about GitHub Pages and Jekyll at https://help.github.com/articles/using-jekyll-with-pages ; in Octopress everything is generated outside of Github.

2. Don’t run git clone https://github.com/imathis/octopress yet

First, if you have a user pages <user>.github.io repository on GitHub — delete it! Octopress works by forking the Octopress repository and adding your content on top of it. I’m not even sure if it’s possible to merge the history from two different repositories in git, but I bet it’s not worth the trouble. Just delete it (back it up first if it has anything in it — or you could just rename it).

Now create a new <user>.github.io repository, and UNCHECK all the boxes: no README, no license, no .gitignore — we want a blank repository with no commits.

3. Okay, now git clone https://github.com/imathis/octopress

4. Run gem install bundler

You need bundler to do everything else, and on Arch Linux it should install under $HOME/.gem/

5. DON’T run bundle install! (If you’re using Arch Linux)

This is important: bundle will ignore that gem is set to install locally (--user-install) by default on Arch Linux, and install everything in /usr. (Okay, you can cancel when it asks for your sudo password, but still). Plus it will install the dependencies for Octopress/Jekyll mixed with anything else you have installed, which is annoying, at least.

You will need to add export GEM_HOME=$(ruby -e 'puts Gem.user_dir') to your shell (~/.zshrc or ~/.bashrc) to get bundler to install gems under your home directory (see https://wiki.archlinux.org/index.php/ruby#Bundler ). However, this is negated by our next step:

Run bundler install --path .bundle. This will make bundler install the dependencies listed in the Gemfile into .bundle/, which is much easier to clean up ¹

6. Don’t run rake setup_github_pages

Since we made bundler install the gems into .bundle/, they aren’t on the PATH. To run the rake installed by bundler, we would need to type bundle exec rake <task>. I for one refuse to type that more than once, so do alias rake='bundle exec rake' to make things easier temporarily (I don’t have a permanent solution for this yet).

7. Whew! Now run rake setup_github_pages

8. Don’t run rake generate yet

First edit _config.yml to customize your site: change some things like title:, subtitle:, author: and maybe add your username to github_user: if you want.

9. Finally! Run rake generate and then rake deploy

• you should see a bunch of output, some of which may be git telling you about missing tracking information for the current branch (don’t worry about this yet)

• you should have source, sass, _deploy, and public directories now

• if you do git status, you should see changes in Rakefile and _config.yml, and untracked directories sass and source

• you should be able to see your new site at http://<user>.github.io/ now (GitHub documentation says it may take a few minutes; I personally haven’t seen a delay in updating yet).

10. Now do git add . and git commit, write a commit message and then git push origin source

With Octopress, the source for generating the site is kept on the ‘source’ branch, and the generated files are committed and pushed to the ‘master’ branch automatically by rake deploy

Now, you could continue to develop your site, add some posts and whatnot — but I recommend you do two things first:

• cd ..; rm -rf octopress
• git clone -b source git@github.com:<username>/<username>.github.io
• cd <username>.github.io
• git clone -b master git@github.com:<username>/<username>.github.io _deploy²

This will help git get straightened out with all of the remote tracking branches etc. The only problem is you have to run bundle install --path .bundle again — oops. Of course I thought of that before deleting the original directory…