Irreal

Roman Numerals. On the one hand, it’s hard to understand why anyone cares anymore. Some, like the late Rich Stevens considered them an anachronistic barbarism and labeled his books “Volume 1, 2, …” rather than the more conventional “Volume I, II, …”. Others continue to label volumes with the conventional Roman numerals and, of course, there’s all those buildings with their erection date labeled, of course, with Roman numerals on their facade.

It used to be that everyone learned how to read and write Roman numerals in School but, according to a teenager of my acquaintance, that’s no longer the case. Were it not for their ubiquitousness on the front of buildings and multivolume books, I’d be happy so see them disappear from our milieu but for the time being, it seems useful to be able to at least read them.

Really, it’s not much of an effort. There are only 7 symbols and they are combined in a regular way to form all the numbers that we’re apt to see today. It’s true that there’s more than one way to form some numbers but all of them are easy to decipher. It’s hard to see how anyone with more than a couple of brain cells to rub together would take more than 15 minutes to completely master the system.

Still, Common Lisp is famous for having functions to convert between Arabic and Roman numerals. That’s less true for Emacs Lisp but there are, apparently, some functions spread across a couple of packages to do the job. Charles Choi doesn’t like that so he wrote a package to provide the capability in a single package.

I suppose, if you squint hard enough, you can imagine cases where you might want to do this sort of thing programmatically but, really, it’s mostly too easy to do manually to need a function. Still, if you do have a need to do this programmatically, Choi has got you covered.

It’s September so there’s a new Emacs Carnival. This month the topic is Obscure Emacs Packages. I have to admit that when I first saw the topic I wasn’t too hopeful that it would be interesting but, of course, I felt the same about the “Elevator Pitch” topic and we all know how obsessed I ended up being with that.

Now that I’ve read my first post for the new topic, tusharhero’s Obscure Emacs Packages, I guessing that I’m going to end up loving this topic too. Tusharhero’s post actually lists 4 obscure packages—none of which I was familiar with—that many Irreal readers might find useful.

By all means, take a look at his post for all the details but I want to mention two of them that I think could be particularly useful. The first is Tinee that is an implementation of Emacs Everywhere specifically for Wayland, which isn’t supported by Emacs Everywhere. The package was written by Tusharhero himself who says it’s not as full featured as Emacs Everywhere but if you’re an Emacs user on a Wayland system, it seems definitely worth taking a look at.

The other package is Emacs Reader by Divya Ranjan. It aims to be a complete replacement for PDF-tools and DocView. It’s still in the early stages but Tusharhero says it has “RIDICULOUSLY better performance and smoothness and responsiveness in comparison to both PDF tools and DocView.” It’s still early days for this package but if it lives up to its promise, it will be a package that almost everyone will want.

Take a look at Tusharhero’s post and see if there’s anything there for you.

In the developer world, we often talk about two types of bankruptcy:

Email Bankruptcy

This is when we have so many unread emails that we simply give up, delete them all, and start over.

Emacs Bankruptcy

This is when our Emacs configuration becomes so big and complicated that we no longer understand it and start over by deleting our configuration and beginning again with a blank slate.

My Anglo-Saxon upbringing pretty much guaranteed that I’d be resistant to either of these. I’m far too anal to leave any email unread or at least scanned. It’s not really much of an issue today since, unlike the old days, I can access and read my email from wherever I am. That and my zero inbox policy ensure that I never get behind with Email.

As for my Emacs configuration, it’s almost 20 years old and while it has grown and had some minor changes, I’ve never felt the need—or even the urge—to quit and start over. It is, in short, an organic entity that grows and changes in step with my needs. Why would I want to abandon it and start over?

All this discussion is in reaction to a video by TrepidTurtle on the Emacs subreddit about Emacs bankruptcy. TrepidTurtle views Emacs bankruptcy as a natural and common process in our Emacs life. He says, for example, that he was aghast to discover that his Emacs configuration was over 2000 lines long and remedied that by deleting his entire Emacs environment—packages and all—and starting over from scratch. Implicit in his argument is the belief that a minimalist configuration is better.

I don’t understand that. My configuration is 2055 lines and while there may be some cruft most of it is carefully curated packages, settings, and bespoke functions that I’ve developed over my Emacs career. Why would I want to delete all that work?

As for having a minimalist configuration, I add things as I need them or think they will enhance my workflow. I see nothing ipso facto virtuous about having a minimal configuration.

Still, people’s opinions differ and you may be sympathetic to the idea of starting over. If so, take a look at TrepidTurtle’s video for some ideas as to how to do that.

A few years ago, starting in 2016, I wrote a series of articles (1, 2, 3) about my favorite Emacs packages and tips. Reading them now, almost ten years later, I find they’ve aged well. I still use everything on the list and my “can’t live without” packages are pretty much the same. I didn’t include Org mode or Magit because, even then, they were given must haves.

I was reminded of all this when I saw a post on the Emacs subreddit from macro_. The post asked what are the must have Emacs packages in August 2025? Once you get past the usual ankle biting, the answers are revealing. Although consult and Ivy were mentioned frequently there seemed to me be less emphasis on actual editing and more on things like LLM and LSP. For example, no one mentioned Steve Purcell’s indispensable whole-line-or-region. I use it many, many times everyday—probably more than any other package.

Still there are plenty of good suggestions in the comments and they are well worth taking a look at. Everybody’s opinion will differ, of course, but I find it really useful to see what others think and why they think it. Sometimes they even convince me to try out one of their favorites. Take a look at the comments and see if there’s anything there that might improve your workflow.

James Dyer has another in his series of posts describing the sanding down of his workflow. This time he troubleshoots and resolves a problem with minibuffer file completion. His specific problem was that he didn’t like the way fuzzy file completion was working.

The default behavior was to have whatever he entered match any file name that had the same letters in the same order even if they weren’t consecutive. What he wanted was to match any files whose name had a substring that matched his input.

As usual, Emacs has you covered. There’s a completion-styles parameter that you can set to get the exact behavior he wanted. Except it didn’t work. It turned out that another function in the call path was resetting completion-styles to the behavior he was trying to avoid.

It wasn’t too hard to fix this and you see how he did it in his post. There was another small issue that he also fixed. Again, see Dyer’s post.

The meat of his post for me was his three conclusions at the end:

1. The source code is always easily available and you can solve most problems by looking to see what is actually happening.
2. Be wary of local versus global settings.
3. With Emacs, there’s always another way. If you don’t like the way something works, Emacs probably provides another way of achieving the same end.

Most people probably aren’t going to care about the issue Dyer was fixing—at least I don’t care about it—but the point is that whatever Emacs is doing that’s not quite right for you, it’s almost always pretty easy to fix it.

Álvaro Ramírez and James Dyer have a problem. The same problem. They sometimes need to reindent a region or the entire buffer. That’s easy enough to do. You can select the entire buffer with Ctrl+x h or select the region you want to indent if it’s not the entire buffer and then call indent-region, bound to Ctrl+Meta+\ by default.

The problem is the current mark and point are destroyed. It would be better to have them restored after the reindent operation. Dyer has an easy solution for the case where you want to reindent the whole buffer. It’s just a few lines of Elisp that you can add to your init.el and bind to a convenient key.

Ramírez took a more general approach. He, too, had the problem when indenting the entire buffer but also when reindenting a function or the result of expand-region. His idea was to implement diverted-mode that recognizes mark-defun, mark-whole-buffer, and er/expand-region and restore the point and mark afterwards.

Both solutions are nice. If you mostly just want to reindent the entire buffer, copy Dyer’s code into your init.el and be done with it. If your reindentation needs are more complex, take a look at Ramírez’s solution. It’s easy to specify additional conditions for diverted-mode as your needs grow.

Maybe this never seemed like a problem to you but if it did, these two solutions are good ways of dealing with it.

I’m writing this on September 1 so there’s a new theme for the Emacs Carnival. Nonetheless, one final Elevator Pitch showed up in my feed and it seemed worthy of a few words. The post is from Philip Kaluđerčić and seems to me to be a particularly well thought out explanation of why one might want to adopt the Emacs way of life.

The term “Emacs way of life” may seem a bit overwrought but I think it captures the way many Emacs users feel about their editor. For a lot of us, Emacs informs the way we think about and approach our computing.

Kaluđerčić starts his post with a short list of things that are great about Emacs and the reasons you might want to embrace it. The list is short but heavily footnoted. The meat of his arguments are in the footnotes, which are much longer than the text they reference. Take a look at them and see what you think.

As I’ve said before, I’m been a bit obsessed with the Elevator Pitch meme and I’m sorry to see it end. I’ve really enjoyed seeing others explain why they love using Emacs. On the other hand, I’m sure the majority of Irreal readers will be happy to see me move onto something else.

Álvaro Ramírez had a problem. The SVG header in the buffer of one of his apps was occasionally disappearing. The problem was that he didn’t know where to look for the bug. Then it occurred to him that he could use the after-change-functions hook to catch when the header was deleted. The problem with that plan was that he’d only get the changed text and he needed to see which of his functions was causing the change.

He solved that problem with a brilliant bit of Elisp that prints the first few entries of the stack frame whenever a change is detected. The whole thing is only 7 lines of code plus an additional line to install it in the list of functions to be called by the after-change-functions hook.

Half the function is involved with printing the results. the other half captures the data. The code is easy to read and understand. The only thing you need to know is that the backtrace-frames function returns a list of frames from the current backtrace and that each of those frames has the format (flag function arguments...). Ramírez uses only the function part (hence (car (cdr frame))) in his function.

After increasing the number of frames printed, he began to see his own code in the backtrace and soon located the offending code. This was an excellent hack and one that Ramírez says he’s gong to keep in his toolbox.

It’s a nice example of how you can get access to the backtrace in your own executing code. It’s a good trick and one that can be easily adapted to fit your particular needs. If you write Elisp, you should read and understand Ramírez’s function. It is, as he says, a handy thing to have in your toolbox.