A little earlier this evening I got a new issue raised against boxquote.el. Apparently Emacs 29 (I'm running 28.1 as of the time of writing) is moaning about the likes of:

(setf (point) some-location-or-other)

and

(setf (buffer-string) "")

There's a whole background to why I've tended to code like that, that stems from enjoying Common Lisp, my days reading (and sometimes posting to) comp.lang.lisp, and I think some of the stuff Erik Naggum wrote back in the day. I won't get into it all now; I'm not sure I can even remember a lot of how I got there given how far back it was.

But...

Wanting to quickly get to the bottom of why the above was suddenly an issue, I dived into the NEWS file and found the following:

** Many seldom-used generalized variables have been made obsolete.
Emacs has a number of rather obscure generalized variables defined,
that, for instance, allowed you to say things like:

   (setf (point-min) 4)

These never caught on and have been made obsolete.  The form above,
for instance, is the same as saying

   (narrow-to-region 4 (point-max))

The following generalized variables have been made obsolete:
'buffer-file-name', 'buffer-local-value', 'buffer-modified-p',
'buffer-name', 'buffer-string', 'buffer-substring', 'current-buffer',
'current-column', 'current-global-map', 'current-input-mode',
'current-local-map', 'current-window-configuration',
'default-file-modes', 'documentation-property', 'frame-height',
'frame-visible-p', 'global-key-binding', 'local-key-binding', 'mark',
'mark-marker', 'marker-position', 'mouse-position', 'point',
'point-marker', 'point-max', 'point-min', 'read-mouse-position',
'screen-height', 'screen-width', 'selected-frame', 'selected-screen',
'selected-window', 'standard-case-table', 'syntax-table',
'visited-file-modtime', 'window-height', 'window-width', and
'x-get-secondary-selection'.

As suggested above... this is my thing, this is how I coded some Elisp stuff. Look through much of my Emacs Lisp code and you'll find me setfing stuff all over the place.

Apparently my style is "obscure". Actually, I'm kinda okay with that if I'm honest.

This is going to be a bit of a pain in the arse; I'm going to have to go through a whole bunch of code and make it "less obscure", at some point.

But...

This isn't the part that had me thinking I must be getting old. Oh no. The NEWS file had another little surprise in store:

** The quickurl.el library is now obsolete.
Use 'abbrev', 'skeleton' or 'tempo' instead.

That.... that's me that is. Well, it's one of the me things. If you run about-emacs, dive into Authors, and search for my name, in any copy of GNU Emacs from the last decade or two, you'll find this:

Dave Pearson: wrote 5x5.el quickurl.el

quickurl.el was a package I wrote back in the late 1990s, back when I was a very heavy user of Usenet, and often found myself posting the same URLs in posts again and again; especially in comp.lang.clipper. As a fairly quick hack I wrote the code so that I could very quickly insert often-used URLs.

Some time later, I got an email from the FSF (I actually think it was from RMS -- but that's an mbox I've long ago lost -- or a backup of it might be in storage back in England, on a DVD), asking if I wanted to contribute it to Emacs proper. This seemed like an odd thing to add to Emacs but, sure, why the hell not?

And so I had my second contribution to a body of code I used a lot (the first being 5x5.el -- which itself was my first ever attempt at writing some non-trivial Elisp code).

So... yeah... here we are. I'm now old enough to have written some Emacs Lisp code, had it required by the FSF for inclusion in Emacs, had it live in there for something like two decades, and then become obselete!

Ever since the whole business of "light mode" and "dark mode" really kicked off in the mobile OS world, I've been a fan of the dark modes. On both Android and iOS/iPadOS, when apps became available with dark modes, I'd switch to it. When the operating systems themselves adopted the switch, that's what I went for. As well as having a love for all things black (anyone who knows me personally will know that), I think it just looks better on mobile devices. I can't quite say why, but it just works best for me.

So, when macOS got a supported dark mode, I instantly switched it on, obviously. Then, within a day, I switched it back to light mode. Surprisingly it just didn't work for me, and I wasn't sure why. Since then I've tried living with it a few times and it's rarely lasted more than a few hours. There was something, something I couldn't quite put my finger on, that didn't sit right.

Last Monday I decided to give it another go. This time, however, I thought I'd figured it out. The "problem" was Emacs! As mentioned back in January, for as long as I've used it (so since the mid-1990s), my Emacs has always had a light background -- probably because that's how it came "out of the box" (I'm talking Emacs in graphical mode here; I started with it on OS/2 Warp and then moved to a GNU/Linux X-based desktop). I figured that the contrast between the colour scheme of Emacs, and the rest of the machine, was the issue here.

I spend most of my working day either in Emacs, or in iTerm2 -- often rapidly switching between the two. I've always run iTerm2 in the usual dark background mode with light text. So I figured the problem was having a dark OS desktop, dark terminal, and then a light editing environment. Eventually that'd feel wrong.

So I decided that, for the first time in about 25 years, I should give Emacs a go with a dark mode. Taking a quick look at popular dark themes I noticed sanityinc-tomorrow-night looked easy on the eye, so I gave that a go (actually, I gave each of the themes in that set a go, initially starting with sanityinc-tomorrow-eighties, but I finally settled on sanityinc-tomorrow-night).

To start with it didn't look too good; not because of a problem with the theme itself, but because, over time, I'd made changes and tweaks to my setup that assumed I'd be using my usual light theme. After some dabbling and tinkering and trying things out, I got it looking "just so".

Having got that working, I then thought it would be nice to be able to have Emacs -- at least on restart -- adapt to me switching between dark and light mode on macOS. It turns out that detecting if macOS is in dark mode is easy enough, the command defaults read -g AppleInterfaceStyle will emit Dark if in dark mode. So, knowing that, I updated my personal package for checking things about the environment that Emacs is in to use that information:

(defconst is-a-macOS-dark-mode-window-p
  (and
   is-a-macOS-window-p
   (string= (shell-command-to-string "defaults read -g AppleInterfaceStyle") "Dark\n"))
  "Are we running in a macOS window in dark mode?")

So, as of now, my Emacs setup is such that, if I'm in graphical mode on macOS and I'm in dark mode, Emacs will use a dark theme, otherwise it'll do what it did before -- with a light background in a graphical mode and a more Borland-a-like blue background when in CHUI mode.

This seems to have made a difference. Almost one week on my work Macbook is still in dark mode, and I've switched both of my personal Macbooks, and my iMac, into dark mode too. I think it's sticking this time. Next up is to give some serious consideration to darkening the web in general. Only now am I noticing just how damn bright most of it is!

As a slight aside to the above, I've also made one other change to Emacs: I've finally dropped the display of scroll bars. In the themes I'm using they didn't look so great, appearing to be distracting. For the past 25 years I've had the scrollbars there, but never actually used them; all they've ever done is serve as a visual aid to where I am in a file. Thing is, I'm not sure I ever really pay that much attention to that either. So, as a test, I've also been running with them turned off and, so far, I'm really not noticing them been gone.

The habits we form that we convince ourselves make sense...

When I started with this version of the blog on Hashnode¹, my plan was to try and write something at least once a week. I managed to do that as far as January this year, give or take, but then things got a little busy, the world got trickier, and... Well, you don't need me to tell you about that. Anyway, I'm back to write some more and, hopefully, try and keep up with writing. I feel it'll do me good.

I have been busy since January. Work has, as far as possible, carried on as normal. The only big difference being I'm back working from home. It's an odd turn of events personally given that I'd worked from home for 21 years, then (with some trepidation) went back to working in an office. Having got used to being in an office and being around people, it took some adjusting to working alone again.

So, on to the main point of this post... During that period I've spent a lot more time at my machine than I would normally, and so it was inevitable that I'd end up tinkering with my Emacs configuration. While it's true that there's hardly a week goes by where I don't tinker with some small thing, I try not to make huge changes too often. Huge changes do happen though.

A handful of weeks back was another one of those times where I made a big change.

After I burnt my original ~/.emacs file back in 2016 I've had an approach where I've tried to make things as modular as possible, and as easy to clone down to a new machine as possible. The design I came up with, especially once I moved over to using use-package, has served me well. But there was always one thing that bothered me: the files that handled the loading and configuration of packages were, in effect, still three large monolithic files. While this was better than a single monolithic ~/.emacs, it still didn't feel quite right.

Giving it a bit of thought, I decided that what I really wanted was a single directory in which I could drop lots of small .el files that would handle the loading and configuration of all sorts of packages. While it didn't gain anything concrete, the idea felt tidier. Tidy is good. Feeling like the code smell is good, is good too.

First though I needed a way to load multiple files, ideally within a whole directory hierarchy, without needing to know in advance what files would be there. After a little bit of tinkering I settled on this bit of code that revolves around the use of directory-files-recursively:

(let ((source (expand-file-name "init.d/packages.d/" user-emacs-directory)))
  (when (file-exists-p source)
    (cl-loop for use in (directory-files-recursively source (rx ".el" eol))
             do (load (file-name-sans-extension use)))))

Simply put, this code finds every file in and below ~/.emacs.d/init.d/packages.d/ whose name ends in .el (note the use of a regular expression, using rx to create it), removes the extension from the name, and loads it with load (dropping the extension means load can decide if it wants to load the compiled version of the code, or the source, depending on what's available).

After writing that I could then start to populate ~/.emacs.d/init.d/packages.d/ with lots of smaller files that handled the loading of packages. In some cases there's a file just for one package, in other cases there's a file that handles a logical grouping of packages (where there are obvious direct dependencies, or where one package is designed to extend the other, etc). For now I've decided to break things down into three directories that map to the three monolithic files I had before:

However, I'm not totally wedded to this design and I may change this as time goes on.

While I've not spent any time properly testing it out, I've also not really noticed any obvious impact on startup speed. However, this tends not to be a real concern for me. I seldom start Emacs anyway. I always have it running and use emacsclient as my editor in most places so files open instantly in the running version of Emacs.

Late on last year I stumbled on an article about dnote. Annoyingly, I can't recall now where I saw it, but I made a reminder to look at it over my Christmas break.

Dnote looked like a tool that would fill a hole I had in how I work. When it comes to making notes about things, and keeping things for future reference, I use a few tools, each one being just right (for me) for the job in question. I use Evernote to track documents and other household type things. I use Keep to make notes about stuff I need to remember short-term (say, the size of a space in my bedroom that I want furniture to go in) and also to record notes while in meetings at work. I use Journey to keep a journal about... anything, really. Finally, I use Pinboard to keep hold of URLs I might want to go back to (I also use it to create a to-read list).

Amongst all of this, however, I felt I was missing something for keeping track of things that don't really fall into any of the categories above. Mostly this would be work-based or hacking-based things that are short and sweet but I don't always use enough to easily remember. I wanted just the right tool that would let me ferret away useful one-liners, remind myself of obscure switches that get used once or twice a year, etc.

After reading up on dnote it seemed pretty clear that this was just such a tool.

After getting back to the office at the start of this month I decided to make use of it and see how it went. My idea was simple: I'd record any "TIL" stuff that I might want to remember in the future, as well as recording things I need now and again but can't always remember.

So far it's working quite well. I like that it has a simple CLI. I like that it's got a backend that you can use to sync between different machines. I like that it's got a web interface that's mobile-friendly. I like that it's Free Software and so you can host your own server if you wish.

I found I liked it enough that, of course, I felt the need to start a simple Emacs wrapper for the CLI.

At the moment dnote.el is designed to be a simple capture system. There are commands for capturing a one-liner (entered in the Emacs mini-buffer), for capturing the content of the current buffer, and for capturing freshly-entered multi-line text, entered in a buffer that uses markdown-mode. There's also a command for syncing notes if you have configured dnote to talk to a backend.

What I don't have right now is the ability to navigate and view notes. So far I've not really felt the need for that because the CLI approach works so well. Longer-term though I can see my tweaking this and adding in commands for searching, viewing, editing and deleting notes.

But, for now, if you've not had a look at dnote, I'd highly recommend having a play and seeing if it makes sense for you. And, if it does, and you're an Emacs user, perhaps dnote.el will be useful too?

Both at work and at home I use Emacs by keeping a copy running all the time, and use emacsclient to open files inside it (including on remote machines thanks to a bit of ssh and heavy use of tramp -- I might write this up at some point). This works really well, but does mean I tend to build up a lot of buffers over time.

Having lots of buffers open isn't generally an issue, and if I'm working on lots of different files in a project during the course of a hacking session it's actually a good thing. But, quite often, I want to tidy up the buffer list, clearing it back to near-zero buffers open. Many years ago, when I had a "proper" tower system running 24/7, with Emacs open all the time, I'd use clean-buffer-list as part of midnight. Along the way that fell out of favour with me, likely because I drifted into using machines that had Emacs open all the time but where the machine wasn't awake all the time.

Eventually I decided to have some fun rolling my own solution, and nuke-buffers was born.

Rather than try and do things in an automated way, this was designed to be bound to a key (or two) and then be run when I wanted, being as harsh as possible about cleaning up the buffer list. Since first writing it it's worked well for me.

These days I tend to let the buffer list build up as I work on a new feature, or chase down a bug, etc. Then, once I've made the final commit for that period of focus, I'll hit the nuke-buffer key combo as the final act of confirming that I've done the job. So not only does this help tidy my Emacs session a bit, it also feels like a physical form of punctuation -- back in less sensible days, when I had some terrible habits, it would have been when I'd reach for the celebratory cigarette; buffer-tidying feels far more wholesome. ;)

The way the code works is, of course, mostly directed at how I work -- it's highly likely it wouldn't make sense for many other people. The main aim is to kill as many buffers as possible, but without disturbing anything else. The list of buffers it gathers for nuking avoids buffers that are visiting files but have unsaved content, avoids the minibuffer (obviously), avoids any "special" buffer (one that starts with a space then an asterisk), avoids the current buffer and also avoids any buffer in a list of names to avoid.

I've being using this on a daily basis for around 2.5 years now and it's done the job without ever losing me any work.

While it does seem that they're a little out of fashion these days, in some circles anyway, I'm still an avid fan of make and make files. Even in environments where I don't need a Makefile to actually build anything, I'll use one (or more) to help create handy shortcuts for getting stuff done.

Looking at the main Makefile for one of my major work projects, there's 45 targets that help fire off various jobs (all of them self-documenting using a variation on an approach I read a while back).

In most cases the targets aren't real targets. That's to say, they don't build the thing they're called. They are phony targets. So, as makes sense, I make a point of marking them all as such. I follow the convention that has the .PHONY marker appear on the line before the target; this feels cleaner to me and easier to follow and maintain.

But.... I'm lazy. And I use Emacs. Typing out .PHONY foo all the time feels like far too much work. So, some time ago, I quickly threw together make-phony.el.

With this I could be really lazy. I could type out the Makefile target and then, with my cursor on it, press a key combination and have the .PHONY marker put in place.

Does it save much time? Yeah, probably not really. But it was a fun little exercise and an excuse to write a little bit of Emacs Lisp.

There's one thing I made a point of doing in the heart of this too: using rx. For anyone who doesn't know of it, think of it as a very Lispy way of writing regular expressions. I won't even try and explain it all here because others have done an excellent job already. What I will do is say this: if you're in the habit of writing some Emacs Lisp, or even tinkering with your configuration, and you find yourself writing a regular expression, consider looking at rx -- it's well worth the time to get to know it.

Slowly, as time goes on, I'm weeding out "vanilla" regular expressions from my config and code and moving over to using rx. I feel, quite rightly I think, that something like this:

(rx
 (or
  ;; Ignore hidden files.
  (group bol ".")
  ;; I never want to edit the desktop.
  (group "Desktop/" eol)
  ;; Ignore compiled files.
  (group "." (or "pyc" "elc") eol)
  (group ".egg-info/" eol)))

is much easier to write, read and maintain, than this:

"\\(^\\.\\)\\|\\(Desktop/$\\)\\|\\(\\.\\(?:\\(?:\\(?:el\\|py\\)c\\)\\)$\\)\\|\\(\\.egg-info/$\\)"

I mean, even if the regular expression above can be written in a more efficient way (and I imagine it can), as someone working in a Lisp environment, I'd much sooner write and work with the rx version.

At the start of this month I spent a very enjoyable Saturday afternoon watching EmacsConf 2019. If you missed it, or even if you didn't, you might like to know that the announcement has gone out that almost all of the videos are now available for watching.

While I mean nothing negative about any other video, I think the two that stand out the most for me, in terms of things that grabbed my interest, were How a Completely Blind Manager/Dev Uses Emacs Every Day and Emacs as my Go To Script Language.

I seem to recall that both those talks were hit with technical issues (many talks on the day were -- part of the enjoyment for me was how the whole conference was an experiment in using Free Software to host the whole thing), but they're well worth a watch despite this.

If you have any sort of interest in Emacs I'd highly recommend dipping into the whole collection.

I really hope there's going to be a 2020 EmacsConf.

As detailed in a blog post I wrote back in 2016, I first got into using Emacs in the mid 1990s, starting with it on OS/2 and then moving over to GNU/Linux. It's been my often-used and much-loved development environment for most of those years (I even have a couple of packages that are part of Emacs itself).

For most of that time my configuration was a single ~/.emacs file, which was around 1,000 lines in length (including comments and whitespace). It'd grown over the years, having special configuration sections for versions of Emacs I didn't use any more, and operating systems I didn't work on any more (yes, really, there were things in there specific to MS-DOS, for example). On top of that I always hand-installed packages I used -- Emacs' package management system having turned up long after I first got into using Emacs.

Then, in early 2016, I decided to nuke the whole thing and start from scratch. As mentioned above, the start of this is detailed in an older post. Another big round of changes happened round a year later -- which included the birth of delpa to manage my personal packages. A couple or so months later there was one last big round of changes, mostly killing off my enthusiastic embracing of customize and instead going back to hand-set settings, only this time done via use-package.

The full history of this can be found over on GitHub, starting with the first "throw everything away and start again" process and all the steps between then and where my Emacs configuration is now.

Which brings me to the fun part of this blog post. Earlier this week I stumbled on Gource. It's a tool that's primarily designed to visualise changes in repositories, although it can be used to visualise anything that has a tree structure and changes over time (this week I produced a video of the growth of my employer's electronic lab notebook by hooking up the Benchling API with Gource, for example). So I got curious. What did it look like as I reworked and tweaked and changed and tinkered with my Emacs configuration?

This is what it looked like:

For anyone who doesn't know, today is the day for EmacsConf 2019. As you might gather from the name, it's a conference all about Emacs, the joys of Emacs, Emacs Lisp and other Emacs-related things.

Better still, it's an online conference (although there do appear to be a couple of related physical gatherings around the world).

I've got snacks and drinks in and no plans for my Saturday, and I hope to follow the whole thing from start to finish.

If Emacs is your thing, or knowing more about Emacs is your thing, be sure to check it out!

gh.fish, which I wrote about yesterday, actually sprang from something I initially wrote for Emacs. I'm often spending my time switching between Emacs and the command line (which is fast and easy -- I normally work on macOS and have Emacs and iTerm2 running full screen, and I can switch between them without ever taking my hands off the keyboard), so it makes sense to have some handy commands repeated in both places.

So, originally, I'd written gitweb.el to open the current repo's "forge" in the web browser.

As with the fish version, how it works is quite simple. I use shell-command-to-string to call git and find the origin URL for the current repo, and then manipulate it a bit to turn it into a normal browser-friendly URL. Finally, if I get something workable, I use browser-url to have the resulting page open in the browsing environment of choice.

I have the command bound to a key combination that's similar to the ones I use with magit and forge, so in terms of muscle-memory it's easy for me to remember what to press when I quickly want to skip over from a magit view to the repo forge itself.

Similar to what I wrote a couple of days back, I think this again illustrates how handy Emacs is as a work environment. While it's absolutely true that there are other development environments out there that offer similar extensibility, Emacs is the one I'm comfortable with, and it has a long history of offering this.