Irreal

Here’s a bit of humor that I’ve had sitting in one of my browser tabs for some time. Over on the Emacs subreddit, Hlorri asks you to Tell me you use emacs (without telling me you use emacs). Although meant to be humorous—and many of the answers are humorous—a lot of them reveal important things about Emacs.

The most common humorous answer involves the strength of the user’s pinky. A typical example is, “I thumb wrestle with my pinky.” Another, that I really liked and could relate to was, “My editor’s config file is older than some of my co-workers.” Several offerings involved the wearing away of the text on the CTRL key.

Among the answers that weren’t so much funny as telling were:

• I expect to get things done in a single app.
• I cannot use essentially any other piece of software without accidentally opening 10 print dialogs or new blank documents/tabs at some point. (and several variations on this theme)
• There’s a mixture of awe, confusion, and mystery when I pair program with co-workers.
• Whenever someone wants to give me any “advice” I frown.
• I interactively do right what other people write programs to do wrong.
• I use the same program for e-mails, coding, calendar and keeping notes (and probably much more).
• I write utilities in elisp instead of bash.
• You mean your code editor doesn’t have a media player, or a planner, or its own window manager?

And a bunch more. Take a look at Hlorri’s post to see them all.

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.