Irreal

The incomparable Sacha Chua has a very nice solution to a problem posed by David Pape: how can we enter a range of numbers as list of distinct numbers in Emacs? Pape’s specific problem was entering the numbers of error reports that a Git commit closes. Rather than entering something like

closes: 47, 48, 49, 50, 51, 70

he’d like to enter something like

closes: 47-51 70

and call an Emacs function to have it expanded into the first example.

Chua has a very nice solution that covers that case as well things like

47-51, 70

or even

5-15/2

to expand into the sequence

5, 7, 9, 11, 13, 15

Most of the heavy lifting is done by the number-sequence function. The rest of the work is parsing the input string into either a single number or a range of numbers that number-sequence can work on.

Chua’s solution strikes me as an example of Emacs at its best. The problem it solves is not earth shattering. It’s simply a bit of friction in a user’s everyday workflow but Emacs easily provides a solution that makes the friction disappear. Take a look at her code. It not only shows an ingenious solution to the problem but also demonstrates the power of Emacs and Elisp to make the application of that genius simple.

Chris Maiorana asks a provocative question: What’s the future of Emacs? He asks that question in the context of assuming that Emacs will continue to exist for any timeline that matters to us. But how, he asks, will we use it?

The answer that will occur to most of us is speech mediated input á la Star Trek TNG. We’ll simply tell Emacs what we want it to do and it will do it. But think about that for a moment. Would you really want to dictate the code for your latest program to the computer? Or would you even want to dictate your documentation, story, or letter to your computer?

Sure, you could say something like, “Computer write a program to do such and such.” but then you’re not using Emacs at all. The same for asking the computer to write something for you. That—more or less—is here today but most of us don’t like the results and, again, we’re not really using Emacs in those situations.

For my part, my written thoughts are always much better organized than my spoken ones so even with capable voice input, I’d much prefer to use the keyboard. Maiorana agrees. He points back to a couple of episodes from Tales From the Darkside¹ in which people use the keyboard to do magic with the computer. For him, Meta+x is the spell that enables the magic and he’s very attached to it. Like me, he doesn’t anticipate abandoning the keyboard.

What do you think? Will we still use the keyboard or will we move on to something better?

Just a quick offering today on an informative post from Ankit Gadiya about unwanted nested frames in Emacs. The TL;DR is that Gadiya runs Ghostel as his Emacs shell in TUI and demon mode. That works well but he has a script that calls emacsclient to load a file. There’s nothing special about it; it’s just what you’d expect it to be but when he runs it from with Ghostel, it creates a nested frame in the Ghostel frame rather than replacing the Ghostel frame.

The solution is pretty simple. Gadiya changed his script to check if he was in Ghostel, and if so, calls emacsclient with a parameter to reuse the current frame. You can check Gadiya’s post for the details.

For me, the most interesting aspect was how he checked if he was in Ghostel. It turns out that Emacs sets the environment variable INSIDE_EMACS when it’s running a shell or subprocess. I didn’t know that so I learned something new from Gadiya’s post.

Update [2026-10-05 Mon 11:15]: Added link to Gadiya’s post.

As we all discover eventually, age is going to be accompanied by declining eyesight. If you make your living writing and coding, this is going to result in some discomfort as it becomes harder and harder to read the text in books, newspapers, or your screen. You can’t do much about printed matter except to get stronger reading glasses but if you’re an Emacs user—or, really, any other editor—it’s easy to increase the text size on your screen. I find myself doing this more often when writing, especially at night when my eyes are tired.

The problem is that the adjustment doesn’t persist across sessions and you have to make the adjustment for every buffer that needs a non-default font size. James Cherti has a solution: persist-text-scale.el.

The TL;DR is that once you set a new font scale for a buffer, it persists across sessions and furthermore you can arrange for all buffers of a certain class to have the same scale settings. That’s perfect. You can, for example, arrange to have all the buffers you use for writing or reading text be in a larger text while keeping other buffers in the default or even smaller text.

Take a look at the GitHub repository linked above for the details. You might also want to check out the comments in Cherti’s Emacs subreddit announcement where he answers some questions on what he’s trying to accomplish with the package. If you’d like to have certain buffers rendered in a larger (or smaller) font, this package may be just what you need.

Charles Choi has been writing a bunch of nice little apps lately—more than I can cover. His latest, Aquí, is sort of a niche application but is potentially useful for more than just its intended use.

The back story is that Choi really likes the sunrise-sunset command in Emacs that tells him the times that the sun rises and sets. The problem is that sunrise-sunset requires that you first specify the latitude and longitude of where you want to know the times. The standard way of doing that is to record them in your init.el, which is what I do. Choi, however, travels with his laptop but still wants to know when the sun is coming up or going down. There’s no automatic way of setting the information so he wrote Aquí to provide it. The only downside is that it works exclusively on the Mac platform.

Once installed, all you need do is call aqui to set all the appropriate information. I hardly ever travel these days so I wasn’t going to bother but it’s easy to use and can give you your current latitude and longitude as well as your address so I thought, “Why not?”. After I installed and ran it, it gave me my exact address as well as my latitude and longitude. That might sometimes vary a bit depending on the vagaries of GPS but it’s certain to be close.

If you decide to try it out, be sure to take a look at the user manual so see what commands are available. Mostly, though, you’ll just need to run aqui. Also be sure to check out the installation section because you need to install a shortcut. That’s just a matter of clicking on a link in the manual but Aquí won’t work until you do.

As I wrote back in July, although I’ve had Embark installed for some time, I’ve only just begun to really use it. Most of my uses involve following a link (of any type) and acting on a group of files, typically to delete several files at once. Of course, those uses are barely scratching the surface of Embark’s capabilities.

Those capabilities are essentially open ended. By that I mean you can define your own Embark actions. Stefano Rodighiero has a nice example of this. It’s a nice example for two reasons. First, it’s simple and easy to follow even though—the second reason—I don’t know anything about what he’s trying to do. The point is that Rodighiero has an obscure—to me—application that he wants to provide an action for but you don’t need to know the details of the application to follow the action.

This is incredibly powerful. Rodighiero let Embark do the hard work of identifying and parsing the target and merely wrote some simple glue to take that target reference and do something useful with it.

If, like me, you’re just beginning to feel your way around Embark, Rodighiero’s post is a useful read. You almost certainly won’t have a need to copy his action but it’s an excellent go by for your own.