Posts in category "Emacs"

Just under a year ago I decided to totally rewrite my GNU Emacs config. As I wrote at the time, it'd been following me around all sorts of machines since the early 1990s, starting life on an OS/2 Warp machine and travelling via MS-DOS, GNU/Linux, Windows and, these days, macOS.

The changes I made last year have served me really well, but there were two related issues with it that bothered me a little: the fact that I was maintaining a local library of Elisp code in the repository and, worse still, I was storing the packages I'd installed from Elpa and Melpa in the repository as well.

While this did mean it was pretty easy for me to start up a new installation of Emacs on a machine -- all I had to do was clone the repo and run up Emacs -- I wasn't happy with the duplication involved. I didn't like holding code in my .emacs.d repo that was already held in package archives.

The solution I saw was in two parts:

1. Get some of my code, that might be useful to others, into Melpa.
2. Somehow sort my own package archive for my personal code.

Over the past week or so I've worked on this approach. It initially started with me tackling item 1 above: I tidied up and submitted obfusurl.el, protocols.el, services.el, thinks.el and uptimes.el. This was a really helpful process in that it allowed me to brush up on my Elisp and Emacs knowledge. It's a good 15+ years since I last wrote any significant Elisp code and things have moved on a little in that time.

Having done that I'd managed to move a handful of my own packages out of my local library of code, and so out of my .emacs.d repo, but it left me with the problem of what to do with the rest of it.

That's when I discovered package-x and:

,----[ C-h f package-upload-buffer RET ]
| package-upload-buffer is an interactive compiled Lisp function in
| ‘package-x.el’.
|
| (package-upload-buffer)
|
| Upload the current buffer as a single-file Emacs Lisp package.
| If ‘package-archive-upload-base’ does not specify a valid upload
| destination, prompt for one.
`----

(plus package-upload-file too, of course). This meant I could, in effect, start my own personal package archive and look at tackling issue 2 above.

This did give me one small problem though: how and where would I host the archive? I did consider hosting it on a DigitalOcean droplet, but that felt a little like overkill for something so simple. And then I realised: GitHub Pages! All I needed to do was keep the package archive in its own repo (which I would have done anyway) and then make the whole repo the source for a GitHub Pages site. A quick test later and... it worked!

So, by this point, I'd farmed some of my code off to Melpa, and now had the rest of it in "Delpa" (which I'd called my personal archive). I could now use the Emacs package management system to install third party packages and also my own.

But I was still left with one issue: I was still holding the installed packages inside my .emacs.d repo by way of ensuring that all machines were in sync in terms of what was installed. Now I needed to work out how to solve that.

Around this time, as luck would have it, @tarsius had suggested I look at a package called use-package by @jwiegley. This was the bit I was missing.

With use-package I would be able to declare which packages I needed, how they'd be installed and, most important of all, it could be set to handle the fact that the package wasn't even installed. If a package is requested and there is no local install use-package is smart enough to get the Emacs package system to install it.

So, given that, all I need to do was create a startup file that would declare the packages I use and I'd have a setup that should, once I'd cloned .emacs.d, self-install.

Except... yeah, one more issue. use-package isn't part of GNU Emacs yet so I'd need a method of getting it to auto-install so it could then handle everything else. As it was that was as easy as adding this to the start of my init.el.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Make sure the package system is up and running early on.
(require 'package)
(add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/"))
(add-to-list 'package-archives '("delpa" . "http://blog.davep.org/delpa/"))
(package-initialize)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Bootstrap `use-package'
(unless (package-installed-p 'use-package)
  (package-refresh-contents)
  (package-install 'use-package))

With that in place I was able to nuke all my config on a machine, clone a fresh copy of .emacs.d (having now ceased tracking and storing the installed packages in that repo), run up Emacs, wait a few moments and then find that everything was installed and ready to use.

Perfect!

My .emacs.d is now a lot smaller than it was before and, I think, even easier to maintain. Right now I think I'm very close to the ideal Emacs config that I wanted to create when I did the complete rewrite a year ago.

As I've mentioned elsewhere on this blog, over the past few years, my use of GNU Emacs has lapsed somewhat. There was a time when it was my only editor (except for the odd dips into vim to do some quick editing) and, back when I used to use GNU Linux as a desktop machine a lot, I'd have an Emacs session up and running pretty much non-stop (it was one of the reasons I wrote uptimes.el).

In more recent times I've been working more on Windows and often inside Visual Studio. Even for my own "for fun" programming, I've mostly being doing things that didn't involve Emacs much. In fact, most of my recent "for fun" coding has been done using Sublime Text because it was powerful, cross-platform and also had great support for the language I code in a lot when it comes to personal amusement projects.

During that time I've wanted to get back into Emacs. Quite a bit seems to have changed since I was last a very avid user and this also meant wanting and needing to catch up.

The first thing I needed to do was finally get around to killing off my old ~/.emacs file. This has followed me around since I first got into Emacs on OS/2 back in the mid 1990s. The file started out with a few setq expressions to tweak some settings and just kept growing and growing. It'd got to a point where there was old stuff in there that I had no use for and sometimes even no idea what it was for. Heck, to give some idea of how old the file was: there were items in there that handled running Emacs on MS-DOS!

So, a couple of weeks back, I dumped it. Dumped the whole lot. The plan then was to recreate it with as little hands-on coding as possible. I decided that, as much as I could, I'd tweak using customize and only hand-code (in ~/.emacs.d/init.el this time around) things when there was no obvious other way to do it.

So far this is working out really well. Gone has the ugly and monolithic .emacs, replaced with something far more modular, much more tidy and far easier to maintain. Whereas my old config was almost 1,000 lines long, the new init.el is currently just 50 lines:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Make use of the Common Lisp compatibility module.
(require 'cl)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Local config/lib directory support.

(defun davep:user-path (path)
  "Given `file', return a path for it in the local config."
  (concat user-emacs-directory path))

(defvar davep:local (davep:user-path "davep/")
  "My local config and code directory.")

(defvar davep:startup (davep:user-path "davep/startup")
  "My local startup code.")

(defvar davep:lib (davep:user-path "davep/lib")
  "My local library code.")

(defvar davep:lib-3rd-party (davep:user-path "davep/lib-3rd-party")
  "My local third party code.")

(push davep:local         load-path)
(push davep:startup       load-path)
(push davep:lib           load-path)
(push davep:lib-3rd-party load-path)

(defun have-own-package-p (package)
  "Does a package of my own exist in this environment?"
  (locate-library package nil (list davep:lib)))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Ensure custom values go in their own file.
(setq custom-file (davep:user-path "custom.el"))
(load custom-file)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Load various startup things.
(load "env-tests")
(require 'davep-keys)
(require 'davep-languages)
(require 'davep-style)
(require 'uptimes)
(require 'csrclr)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Local autoloading.
(require 'autoloading)
(load-davep-autoloads)

All the other stuff, things to tweak language modes so they indent "just so", my own special keyboard bindings, that sort of thing, they're all farmed off into their own files:

davep@Bellerophon:~/.emacs.d/davep/startup$ v
total 40
-rw-r--r--  1 davep  staff  4211 24 May 14:38 davep-keys.el
-rw-r--r--  1 davep  staff  4078 16 May 13:51 davep-languages.el
-rw-r--r--  1 davep  staff   537 25 May 14:13 davep-style.el
-rw-r--r--  1 davep  staff  1339 16 May 09:39 env-tests.el

Another thing I'm trying to do is dump all the old third party code I had locally and, instead, use Emacs' own package manager now. Currently this is also working well for me given that I'm using both ELPA and MELPA.

I haven't managed to dump everything yet, but it's a useful exercise to slowly work through the various files I was carting around and deciding if I need them or not (like, I'm fairly sure I won't be needing a cobol-mode any time soon -- that can go).

On top of all of this, on top of starting with a "clean slate" Emacs, I've also started keeping track of what I do on GitHub. I've got a private repo for my ~/.emacs.d/ that I can now easily sync between my various machines.

One final thing that I'm starting to try and do is actually make full use of Emacs again. One example is that I'm writing this blog post in it. Until now I've been using SublimeText with a Jekyll package to compose and manage things but, this time around I'm giving Hyde and markdown-mode a go. So far they're working out pretty well too (albeit Hyde was a bit odd to set up and isn't 100% making sense to me yet).