↓ Skip to Content Start of content

My minimal Emacs configuration

My full Emacs configuration consists of multiple packages and a few thousand lines of elisp code. The whole thing is then synchronized between my development machines so that I have a common environment to work in.

This setup works well enough, but it's a little heavyweight. For machines that don't require the full configuration - such as a Raspberry Pi - I use a much more streamlined setup. This version strips away some graphical elements I don't use, puts backup files in a single location, and sets up packages that I use every day.

The packages I use most frequently are:

;; Turn off menu bar, tool bar, and scroll bar.
(if (fboundp 'menu-bar-mode)   (menu-bar-mode   -1))
(if (fboundp 'tool-bar-mode)   (tool-bar-mode   -1))
(if (fboundp 'scroll-bar-mode) (scroll-bar-mode -1))

;; Turn off the splash screen.
(setq inhibit-startup-message t)

;; Set path to .emacs.d
(setq dotfiles-dir (file-name-directory
		    (or (buffer-file-name) load-file-name)))

;; Don't use tabs for indentation.
(setq-default indent-tabs-mode nil)
(setq-default tab-width 4)

;; Enable upcase/downcase region.
(put 'upcase-region   'disabled nil)
(put 'downcase-region 'disabled nil)

;; Store backup files under ~/.emacs.d/backups
(setq backup-directory-alist `(("." . ,(expand-file-name
					(concat dotfiles-dir "backups")))))

;; Maximize window when frame opens.
(add-to-list 'default-frame-alist '(fullscreen . maximized))

(require 'use-package)

I use helm for finding files, switching buffers, and running commands with M-x. The configuration looks like this:

;; -------------------------------------------------
;; -- Helm - automatic completion buffers.

(use-package helm
  :diminish helm-mode
  (require 'helm-config)
  (customize-set-variable 'helm-ff-lynx-style-map t)
  (customize-set-variable 'helm-imenu-lynx-style-map t)
  (customize-set-variable 'helm-semantic-lynx-style-map t)
  (customize-set-variable 'helm-occur-use-ioccur-style-keys t)
  (helm-mode 1)
  (add-to-list 'helm-completing-read-handlers-alist '(switch-to-buffer . ido))
  :bind (("C-c h" .   helm-mini)
	 ("M-x" .     helm-M-x)
	 ("C-x C-f" . helm-find-files)
	 ("C-x b" .   helm-buffers-list))
  (helm-candidate-number-limit 100)
  (helm-idle-delay             0.0)
  (helm-input-idle-delay       0.01)
  (helm-quick-update           t)
  (helm-M-x-requires-pattern   nil)
  (helm-ff-skip-boring-files   t))

If I'm doing any kind of programming work I'll want magit and projectile installed too. I use the defaults for magit, and my projectile configuration is also pretty slim:

;; -------------------------------------------------
;; -- Projectile - project navigation

(use-package projectile
  :diminish projectile-mode
  (projectile-keymap-prefix     (kbd "C-c p"))
  (projectile-enable-caching    t)
  (projectile-completion-system 'default))

(use-package helm-projectile
  :init (helm-projectile-on))

Finally there are some key bindings that I like:

;; Disable C+z closing because I'm too clumsy.
(global-set-key "\C-z" #'ignore)

;; Use M-` to switch between frames.
(global-set-key "\M-`" #'other-frame)

;; Jump to a line number.
(global-set-key "\C-x\C-l" #'goto-line)

Daily vs weekly writing

Last year I took part in a 30 day blogging trial. It went pretty well, so this year I'm aiming for 100 posts over the course of the year. There's less pressure when publishing twice a week, but I'm finding it harder to write on this schedule.

I think this is related to my game development struggles; I've written games in 48 hours, but give me a month to do it and suddenly I fall apart.

There are some advantages to writing twice a week. I can spend additional time writing more detailed posts. There were some things I wanted to write about during my 30-day sprint that I didn't have the time to do. With a full week I can give them more attention they need.

However, on the twice-weekly schedule I'm rejecting more ideas and leaving more posts in the "draft" folder. Having that daily deadline pushed me to get ideas out the door as I didn't have time to get them "perfect". I think that's probably true of all my creative work.

Ideally I'd like be able to mix in daily writing with longer posts. I found daily writing to be helpful when exploring ideas, but it requires a lot of time and mental energy. I might end up with a hybrid approach where I post daily for a week and then write a longer article the week after.

Managing Pocket highlights with Zettelkasten

I've been using Pocket to manage my reading list for about a year now. There are a couple of features that I really like:

  • Articles can be saved directly from Firefox and then picked up later on a different device.
  • Articles can be tagged with one (or more) categories.
  • Highlights can be added and saved in the reader view.

I frequently highlight articles, but I realized I don't actually do anything with them. It doesn't really matter how vigilant I am about highlighting interesting ideas if I don't make use of them.

As part of my goal this year to improve my processes, I wanted to get these highlights out of Pocket and into my zettelkasten system.

The current process I'm using looks like this:

  • Step 1 - Create a single note for the article which contains all of its highlights.
  • Step 2 - Read through each highlight and decide if it's something I want to keep or convert.
  • Step 3 - Rewrite the book highlight in my own words as a new note.

It follows a similar thought process to my GTD setup: notes come in, I decide what to do with them, and then I convert them to something else or discard them entirely.

Step 1: Fleeting notes

A zettelkasten system contains different types of notes: fleeting, literature, permanent, and index.

I treat all book highlights as fleeting notes. These function a lot like items in GTD's inbox; they may end up being converted into a different type of note, or they may be trashed if they're not as interesting as I originally thought.

All highlights from an article go into the same note, with the article url at the bottom so I can go back to it if needed. Keeping things simple is key.

This is meant to be a pretty quick step; I copy and paste each highlight as an org-mode quote and don't make any decisions until step 2.

Step 2: Processing

I re-read each highlight and choose the next step:

  • If it's not actually that interesting, I'll delete it.
  • If it's something I want to take direct action on, I'll move it to my GTD inbox.
  • If it's interesting and non-actionable, I'll move on to step 3.

During the copying process I usually have a good idea about what I'm going to do with the highlight, but I don't actually do anything until this step. Having distinct stages prevents me from getting distracted with re-organizing my notes.

Step 3: Rewriting

My high school physics teacher often told me to "make the material your own" by rewriting it, rather than copying it directly. I wasn't very good at physics, but I still remember the things that I took the time to make personal.

Step 3 is about making the information my own.

It's worth spending the time to really think about what was highlighted - and why - so that the information is absorbed. Without this step I'm just hording other people's words without integrating it into my own knowledge.

I'll then split my rewritten note - sometimes with the quoted highlight - into a separate note. I link to this new note from the original one, and then delete the saved link from Pocket.

An example note

This is a note from the article "How to Improve Your Productivity as a Working Programmer" before processing:

A complete note before processing

And this is what it looks like after processing and editing:

A fully-processed note

The finished note has no content of its own, but acts as an index to all of its related notes. Sometimes I'll add a little excerpt or summary to the top if the title is non-obvious.

An extracted note looks like this:

An extracted sub-note

By the end of the process the note has been turned from a few chunks of copy-pasted text into a page that links to my personal thoughts about an article. It's a fairly quick process once I'm in the groove, although I need to get better about scheduling it as frequently as my weekly GTD reviews.

One important part of this system is to be comfortable with rearranging things. When I first started keeping notes I wanted everything to be perfectly organized on the first try, but it often takes multiple passes before I'm completely happy.

Further reading:

Getting started with plaintext accounting

For a long time I used Microsoft Money to manage my accounts, but that was eventually retired and stopped working. I had to find other options so I picked the easiest option - nothing.

A couple of years ago I started looking into setting up an actual system. I had a few requirements:

  • I didn't want an online-only solution.
  • It had to work on all platforms I use (GNU/Linux, MacOS, and Windows).
  • I didn't want a third-party storing my bank details.

In the end I settled on using ledger. It runs locally, stores everything using plain text, and doesn't require any remote service to work. And as a bonus there is ledger-mode which adds ledger integration to Emacs.

My system at the moment is pretty basic: I split each of my accounts into separate directories, and then use one file for each year. I also have a primary file that links to all of these files; this allows me to run reports across all of my money.

There are some pretty big things I want to improve on in my setup: importing entries takes time, I'd like to learn how to run better reports, and I want to set up a YNAB-style budget system.

By far the biggest pain-point right now is importing entries. Currently I have to manually download CSV files from my bank, convert them with a script, and then go through each item to remove duplicates and categorize the data. Ideally I'd like to be able to automate the entire process, but I'll be happy if I can simplify the conversion and importing process.

Resources to learn more:

Provides a complete overview of the different applications available, along with instructions on getting started.
A community for discussing the ins-and-outs of plain text accounting.

New section for deliberate practice

One of my goals in 2021 is to spend more time on "deliberate practice". This is something I've written about before, and after reading Mastering Software Technique I decided to put some effort into improving my skills.

I'm treating this section like an online notebook. It's also a way to keep me focused on deliberately learning things instead of aimlessly messing around. A lot of these projects will be small - ideally only a few hours in length - but I wanted to keep track of them somewhere.

2021's section is a little barren right now, but I'll be adding more projects as the year progresses.