Posts tagged with "Lisp"

In the last month or so, as I've mentioned a few times before, I've been trying to tidy up some of my older personal Emacs Lisp packages. I thought I'd updated all the ones I commonly use, but it turns out I hadn't. Somehow I'd missed become.el.

This is another one of those packages whose content started out as ad-hoc commands, added to the ~/.emacs that first started to emerge as I got to know Emacs on OS/2 and then GNU/Linux back in the mid-1990s. I think it was back in 2016¹, when I did a big revamp of my Emacs environment, that I moved all of those roughly-related commands out into their own file.

Honestly, I think I can dump most of them now. There's stuff in there for quickly and easily converting buffers between "DOS format" and "Unix format" (from back when I was still working a lot on Windows machines, and sometimes even in MS-DOS-based virtual machines, and often using the DJGPP-built version of Emacs).

One command I still use all the time is become-free-of-trailing-whitespace, because I have that set up as part of a before-save-hook:

(use-package become
  :ensure t
  :defer t
  :vc (:url "https://github.com/davep/become.el" :rev :newest)
  :commands become-free-of-trailing-whitespace
  :init
  (unless noninteractive
    (add-hook 'before-save-hook #'become-free-of-trailing-whitespace))
  :bind
  ("<f12> <tab>" . become-freshly-indented-no-tabs))

While I know that there are better ways of handling the trailing space issue these days, this is one I rolled for myself a couple of decades ago and it's yet to fail me. You can see just how dated it is from this:

(cl-flet ((is-sig-line ()
                       (save-excursion
                         (beginning-of-line)
                         (looking-at "^-- $")))
          (markdown-br-p ()
                         (save-excursion
                           (beginning-of-line)
                           (and (eq major-mode 'markdown-mode)
                                (looking-at "^.+[^ ]  $")))))
; ...body removed
)

If you know, you'll know why is-sig-line is there².

I do still use become-freshly-indented-no-tabs on occasion too, and have it bound to an easy-to-remember and obvious (to me) key.

And so, despite the fact that most of the content of become.el is probably obsolete at this point, despite the fact that there are probably far better and more idiomatic ways of doing these things these days... it's my little personal package that has grown with me in the 3 (and a bit) decades I've had Emacs under my fingertips. I'm going to keep it around just a little longer.

The simplification of my mode line is sticking, in that I like how it's turned out and I find it more useful to have it this simple. But I did notice something was missing: I'm a pretty constant but pretty casual user of projectile. I know it's a package that offers a wealth of tools, yet mostly I just use it as a project bookmark system. For this, though, it works well.

Given this, having a quick and easy way to check that I'm in the project I think I'm in is a good idea. While I also have neotree open all the time, which gives a fairly obvious clue, my eyes keep flitting down to the mode line.

The change I made the other day, deliberately, left the project off. I think this was a simplification too far. So now it's back.

The core of my mode line configuration now looks like this:

(setq mood-line-format
      (mood-line-defformat
       :left
       ((or
         (mood-line-segment-buffer-status)
         (propertize
          (mood-line--get-glyph :buffer-modified)
          'face 'my/mood-line-good-status))
        " "
        (mood-line-segment-buffer-name)
        (my/mood-line-segment-project)
        " "
        (mood-line-segment-major-mode))
       :right
       ((my/mood-line-segment-vc)
        " "
        (propertize
         (mood-line-segment-cursor-position)
         'face 'my/mood-line-cursor-position))))

A little busier than it started out, but still pretty clean. I do keep wondering about the cursor position. In most buffers I have line numbers showing to the left anyway, and it's rare (but not unknown) that I need to know what column I'm in. I'm very tempted to remove the cursor position altogether, then the right-hand side would just be the vc information, at which point it might make sense to also move the project name over to the right, given that the project and the repository information generally go hand-in-hand.

I'll stick with this for now, but I can see this happening soon.

I've released blogmore.el v5.3.0. This is a pretty small release but adds a command I realised I'd forgotten to add a couple of releases ago.

Now that BlogMore has the concept of a post series, and now that blogmore.el lets you add and remove a series from a post, it makes sense that I'd want to link to a series in a post from time to time, like I can and do with categories and tags.

So v5.3.0 adds a blogmore-link-series command. It can also be found in the transient menu.

By pure coincidence, it's six years ago tomorrow that I finally, after years of running Emacs with a bright white background, moved to using a dark theme. It took a little bit of getting used to but eventually I got very comfortable with it, and since then have run everything I can in a dark mode too.

On occasion, in the last year or so, I've had this urge to move to something darker. Also, in part, it's an urge to change things up a little. I felt it was time for a refresh of how my Emacs looks. I've tried a few themes, but none have ever stuck. When trying them I've run into various issues:

• It just didn't look nice at all
• Too many other things I use in Emacs didn't get themed
• It looked like there was going to be too much work to do to really theme things well
• It caused Emacs to crash¹

However, yesterday evening, after making an effort to simplify my mode line, I was determined to find a darker theme that I would be happy with. I think I finally managed!

I've settled on modus-vivendi from modus themes. Out of the box it felt right, and from what I can see in the documentation there's an amazing amount of customisation you can do. The key point there too is the documentation; there's so much of it, it's incredibly comprehensive.

For example: the default choice for the mode line is to have an unsubtle border around it -- presumably to create a good contrast. I found that far too distracting and was wondering what I could do about it. I didn't have to wonder long, the documentation addresses exactly that situation.

Another downside I ran into is that the colours that were showing in the mode line, when I switched to mood-line yesterday, were gone. I spent a short amount of time last night, and a good hour or so this morning, trying to wrangle mood-line into something I liked, but I just couldn't get anything sensible going. Eventually I cracked, fired up Antigravity, prompted it with:

I am using mood-line for my mode line -- see init.d/packages.d/melpa/mood-line.el and https://github.com/emacsmirror/mood-line

I am using https://protesilaos.com/emacs/modus-themes as my theme

I would like to have finer control over the parts of the mode line I've configured. For example, I'd like the buffer name to stand out in an informative colour, but one that is part of the modus theme's colour scheme.

Don't make changes yet, but help me understand how I should do this in a maintainable way.

and then spent about 20 minutes going back and forth, refining what I wanted; this got me a result I'm happy with from a visual point of view. I still need to fully review the code and the approach it took, but it isn't too far removed from what I'd been trying myself.

Overall I'm pleased with the result, and this is the longest I've stuck with a new theme (at this point I'm probably about 4 or 5 hours into working in it). I think that says something significant. I can see myself still wanting to tweak some aspects of it though. For example, the left-hand fringe doesn't feel quite right, in a way I can't quite put my finger on. While I want it to stand out from the main editing area, it feels... disconnected in some way. Also the background colour of the mode line still feels like it doesn't quite blend how I'd like.

Now to see if this lasts...

Every so often I get the urge to change how Emacs looks. Ever since I finally fell to the dark side, my Emacs has stayed looking pretty much the same. I like how it looks, but I do keep having this urge to find a darker theme, and to also make things just a wee bit more minimal.

At one point I was very much about, and in favour of, having as much information as possible in the mode line. Eventually I realised I didn't use that much and tried to declutter somewhat, mostly cleaning up minor mode information with diminish. Even then though, I had this feeling that there was still more information in the mode line than I really needed.

So, just now, as an experiment, I've decided to start fairly clean. I've dropped powerline and instead decided to have a play with mood-line. Rather than use one of its pre-configured formats, I've had a go at rolling my own:

(setq mood-line-format
      (mood-line-defformat
       :left
       (((mood-line-segment-buffer-status) . " ")
        ((mood-line-segment-buffer-name) . " : ")
        (mood-line-segment-major-mode))
       :right
       (((mood-line-segment-vc) . "  ")
        (mood-line-segment-cursor-position))))

So far I'm really pleased with the result.

For any given buffer the mode line display is now:

• The status of the buffer
• The name of the buffer
• The major mode of the buffer
• The git status for what I'm working on
• The cursor position

Honestly, I'm struggling to think of anything else I really need to see. Sure, I can imagine there's the odd minor mode I might need to know about, but generally I either have them enabled all the time anyway, or it's something so obvious that I know when it's not enabled.

I'm going to run with this for a while now and see how I feel. I can sense that I might want to tweak a couple of things (at the moment the left-hand side will move when I change the unsaved status of the buffer; on the right there's nothing that tells me that this file I'm editing right now is new to the repo and not part of it yet), but this basic configuration feels clean and right.

Meanwhile... the search for a theme that is darker and I actually prefer over the sanityinc-tomorrow themes continues. I fear this is going to be a lot harder.

Another quick update to blogmore.el, again to fix an issue I've run into with the new frontmatter-handling code. This time it's to address an actual crash that could happen if a property was available but empty. For example, if a post had frontmatter that looked like this:

title: "blogmore.el v5.2.0"
date: "2026-06-12 08:31:15+0100"
category: Emacs
tags:

And I then went to use blogmore-add-tag, I'd get a crash saying:

Wrong type argument: sequencep, :null

The reason being that tags was being parsed with a value of :null, rather than (as before) having a value of nil (which of course meant I had a nice empty list to do things with). It was an easy enough fix.

At this point I think I've managed to shake out any serious issues with the proper YAML-parsing approach to frontmatter, as I've used it to write a handful of posts now.

A quick little update to blogmore.el to fix a couple of issues introduced by the new YAML-parsing approach to reading frontmatter; both pretty much stemming from how falsy values are handled.

Simply put, both boolean false values, and also empty values (something that could commonly happen with tags and series) would end up showing up in the frontmatter as null. This release handles that situation.

Also, under the hood, I cleaned up some repeated boilerplate related to how the cached dump calls to BlogMore took place. The code for categories, tags and series data was almost exactly the same, save for the actual name of the thing being dumped. So I turned it all into a macro:

(defmacro blogmore--cache-dump (dump-name)
  "Generate a function to get DUMP-NAME from BlogMore, with caching."
  (let ((cache-name (intern (format "blogmore--current-%s-cache" dump-name)))
        (getter-name (intern (format "blogmore--current-%s" dump-name))))
    `(progn
       (defvar ,cache-name nil
         ,(format "Cache for the list of %s from existing posts." dump-name))
       (defun ,getter-name ()
         ,(format "Get a list of %s from existing posts." dump-name)
         (or ,cache-name (setq ,cache-name (blogmore--list-of ,(symbol-name dump-name))))))))

and now the defvar that creates the variable that holds the cache, and the defun that creates the getter function for the data, are reduced to this for all three collections of values:

(blogmore--cache-dump categories)
(blogmore--cache-dump tags)
(blogmore--cache-dump series)

Sure, I probably could have done all of this in a single global, a central getter function, and a hash table, but the macro approach feels so much more elegant, and more... lispy.

When I released blogmore.el v4.7.0 yesterday I finished off by saying that it was my intention, at some point, to rework the frontmatter-handling code so that it did proper YAML parsing. As often happens with these sorts of things, "some point" ended up being that evening.

I've rewritten everything to do with handling properties in the frontmatter so that it now uses yaml.el. This has a number of knock-on effects. The first and most obvious effect is that anything that is a list/array in the frontmatter is actually properly treated as a list. A good example here is tags. Now you can have your tags look like:

tags: [BlogMore, Emacs, "Emacs Lisp", Lisp, "blogmore.el", coding]

or:

tags:
  - BlogMore
  - Emacs
  - Emacs Lisp
  - Lisp
  - blogmore.el
  - coding

and blogmore.el will still handle things fine. The same holds for series too.

It should be noted, however, that because I'm now using actual YAML serialisation code, most other forms of a list will all end up being transformed into this kind:

tags: [BlogMore, Emacs, "Emacs Lisp", Lisp, "blogmore.el", coding]

So if you have a bare list:

tags: BlogMore, Emacs, "Emacs Lisp", Lisp, "blogmore.el", coding

and you make an edit to the tags via blogmore.el, it will end up as the version enclosed in []. BlogMore itself supports all three versions so this works fine.

There is a breaking change here too, which in part explains the reason I bumped the version to 5.0.0: because series can now be treated as a list I've removed the blogmore-set-series command and instead replaced it with blogmore-add-series and blogmore-remove-series. Both can of course be found in the transient menu.

Another big change in this release is the way that existing values are loaded up from your blog. Previously, when you went to add a category, tag or series, blogmore.el would use ripgrep (or a combination of find and grep if rg wasn't available) to pull out values to help populate a completion list. This worked fine as long as a) the frontmatter property was all on one line and b) the body of a post didn't contain something that looked like a frontmatter property. With this release of blogmore.el I've dropped this approach in favour of calling blogmore itself and using the dump command to get the actual lists of categories, tags and series.

This does mean that BlogMore needs to be installed in a location where blogmore.el can see it, and to help with this I've added a new defcustom called blogmore-command. By default this is set to call whatever version of blogmore can be found in your exec-path; if this results in unexpected behaviour you can set blogmore-command to point to a specific copy of blogmore.

There is, however, a small downside to this beneficial¹ approach: calling on blogmore and parsing all posts to get the values is generally going to be slower. With this in mind I've built in a cache for these values. The first time you load up the categories, tags or series, the values are held on to so that subsequent prompts are instantaneous (meaning there is no further call to blogmore). To ensure this doesn't confuse things, when you switch blog (blogmore-work-on) the caches are cleared. In the unlikely event that there is a problem with this approach, I've also added a blogmore-clear-caches command to force the clearing of the caches.

There are some other small QoL changes under the hood and also to the interface. I've moved some things around in the transient menu, and also ensured that a couple of options are better-disabled depending on the context.

All of this makes the package even more robust. Something that started as a quick hack back in March has turned into a tool I heavily lean on. Hopefully, for anyone who might happen to use BlogMore and GNU Emacs, it'll be a useful daily-driver for them too.

A quick update to blogmore.el. Having recently added series support to BlogMore it made sense that I then add a quick way of adding a post to a series in the package.

You can, of course, set a new one too, but the idea here (as with categories and tags) is that you can quickly find back an existing series and add the current post to it.

Also, as with tags, the expectation is that either a single series is being used, or if more than one series is in play for a post they'll be listed as a comma-separated list. The issue here is that while BlogMore supports this:

series:
  - Some series of posts
  - Some other series of posts
  - Yet another series of posts

the frontmatter-handling code in blogmore.el isn't very sophisticated at all; it doesn't actually handle it as actual YAML, instead just treating it as a set of key/value pairs separated by a colon.

At some point soon I want to give blogmore.el a revamp and base all of the frontmatter-handling code on something like yaml.el. I did do some experimenting last night to drop it in and handle proper lists. It worked well enough, but I abandoned the work as I realised I really wanted to start again from scratch and build blogmore.el from the bottom up using that package.

Some time soon...

After adding floating and inline tables of contents in BlogMore the other day, it was time to update blogmore.el to include commands to toggle the related frontmatter.

So, with the release of blogmore.el v4.6.0, two new commands are now available:

• blogmore-toggle-show-toc toggles the show_toc frontmatter property.
• blogmore-toggle-show-toc-inline toggles the show_toc_inline frontmatter property.

Both have also been added to the transient menu so they're easy to discover and use.