Irreal

A couple of weeks ago, I wrote about Álvaro Ramírez’s time-zones package. It’s a package that expands on the built in world clock function by allowing cities to be added and deleted on the fly and by allowing the target time to be adjusted forward or backward.

When I wrote about it, it had just been released and was not yet on Melpa. Now, thankfully, Ramírez has added it to Melpa and made some enhancements, such as implementing DST and UTC. The original Irreal post got a couple of comments from people who have installed it and they seem happy.

Ramírez is an independent developer and provides apps such as time-zones as a public service. You can download and use it for free but it’s also important to support his efforts. The best way of doing this, I think, is by buying one or more of his paid apps such as Journelly, which I’ve written about many times. I use it constantly, several times a day and, at this point, couldn’t live without it. You’ll be helping Ramírez and yourself by getting a copy. If you don’t want to buy one of his apps, you can become a sponser.

As most of you know, I’m a true believer in the idea of “living in Emacs”. I’ve imported every task possible into Emacs to the point where virtually all my tube time is spend either in Emacs or my browser. My third most used application is Apple’s Messages but it’s a distant third. Everything else gets immeasurably small use.

This has always seemed right and obvious to me. At the same time I’ve always been dismissive of the newer notion of living in your browser. Why would anyone—other than Aunt Millie—want to do that, I thought.

Then I read this Daring Fireball post on ChatGPT Atlas. Gruber is not a fan for reasons you can read in his post if you’re interested but the thing that resonated with me was this quote:

But, for me, my browser is not “where all of [my] work, tools, and context come together”. I use an email app for email, a notes app for notes, a text editor and blog editor for writing and programming, a photos app for my photo library, a native feed reader app for feed reading, etc.

When I read that, I thought, “See? That’s why I live in Emacs. Who wants to deal with all those separate applications?” And then I thought, “You know, I could make a blog post out of that.” Of course, as Paul Graham said, writing down your thoughts usually reveals that you didn’t really understand them. That’s what happened to me. As I started to lay out this post, I realized there was a contradiction. Why is living in Emacs a self-evident good and living in the browser something only Aunt Millie would do? More generally, if you’re going to have one app to rule them all, why should it be Emacs?

It’s a reasonable question but there’s a good answer. In a sense, all my Emacs posts are answers to that question. Let’s restrict the discussion to just Emacs and the browser. It doesn’t seem to me that there are any other serious contenders.

When I’m in Safari there’s not much I can do to adapt it to my way of working. Sure, there are some UI adjustments and other settings to tweak and I can even use emacs-everywhere and Vimari but basically I have to work the way the browser authors thought I should. Even if I were using, say, Firefox, which is open source and theoretically open to user change, browsers are sufficiently complex that user modifications are not a realistic option.

Emacs is different. Even putting aside its extensive user level configurability, it’s easy to modify the way any particular function works. You can make your desired changes, install the source in your init.el and those changes will be reflected whenever you load Emacs. Similarly, you can write entirely new functions in the same way. You don’t need to understand everything about Emacs to do this, only enough Elisp to express your desired behavior and a few simple rules to install it.

My conclusion is that I’ll continue living in Emacs and that Aunt Millie and other non-serious people are welcome to live in the browser.

JTR over at The Art Of Not Asking Why has a post that explores why Emacs is the right thing. He begins with a story of a Porche owner who often has to drive in countries that require cars to have right hand drives¹. Rather than give up their beloved Porche, they simply modified the car to have an adjustable steering wheel that could be set to either side.

JTR, of course, compares this to using Emacs. Others may lay down restrictions but with Emacs you can simply change it to adapt to those restrictions. As JTR says, sadly, for a lot of apps, configurabilty boils down to choosing between light and dark modes. Those apps force you to work the way they want you to. They give no thought to how you like to do things; they provide a solution and you have to use it whether you like it or not. These apps present a mental challenge: you have to do things that aren’t natural to you in order to work with them.

An example that JTR gives is date formats. Apple apps and many others prefer the US date format but the YYYY-MM-DD format is clearly superior. For one thing, it will sort dates correctly. I think of it as being like the Chinese personal naming convention of Last Name followed by first name. It’s the same principle of stating things in order of more general to more specific.

The main point is that Emacs allows you to adjust it to work the way you prefer. That’s sadly lacking in the majority of applications.

Ediff is a thing of beauty. It provides a way of not only seeing the difference between two files but for merging various differences into a third combined file. It’s very powerful and flexible. The problem is that using it can seem extraordinary complex. There’s a command menu that may or may not appear in your current frame but even if it does there are a plethora of options most of which are unfathomably opaque.

Charles Choi is once again easing our pain by providing a transient menu that tries to bring sanity to the confusion. His new package, casual ediff, tries to cut through the confusion. Take a look at his post to see causal ediff in action.

Ediff is really powerful and every Emacs user should be able to use it. Choi’s casual ediff can help with that but as I learned from this video from Prot, you can ignore most of the complexity of ediff. There are really only a very commands that you need to know. As I said in my post about Prot’s video:

All you really need to know is n for the next diff, p for the previous diff, and a, b, or c to move the A, B, or C diff to the other buffer(s). That’s it. It covers almost everything you ever really want to do in Ediff.

If you’re casual suite user, by all means include casual ediff in your repertoire but if you’re not and just want to make using ediff as simple as possible, take a look at Prot’s video.

Christian Tietze has a nice post on sharpening the Emacs saw as part of this month’s Emacs Carnival on Maintenance. Like many of us, Tietze found that he was moving more and more of his work into Emacs. Finally, he found himself with a bespoke Emacs that was his alone.

Once you have your very own personalized Emacs, you have to maintain it. It’s not necessarily that way for other editors. I was a Vim user for over two decades and very rarely did any maintenance other than compiling and installing new versions. With Emacs, it seems as if I’m always tweaking some setting or adding a new package.

Tietze compares this to taking care of your tools and work area in, say, a woodworking shop. As he puts it, you can’t cut with a dull saw. You need to take care of your tools, not just use them. Equally important, you need to think about how you use your tools and what you’ve accomplished with them in the past.

Tietze says that he considers the time spent tinkering with Emacs and personalizing his computing environment as an investment in his future. It’s like sweeping out and organizing the shop and keeping everything neat and tidy so that you can work unfettered by distracting clutter.

Tietze makes a point I’ve often made myself. Once you shape Emacs into the computing environment that’s specialized for you, you have a perfect tool that you can take with you wherever you go. In our environment, that means whatever operating system or computer you’re using. Emacs runs just about everywhere.

Courtesy of a post from the_cecep over at the Emacs subreddit, I just discovered a builtin gem I didn’t know about. The post is about the delete-pair function. The idea is that you have some text surrounded by a pair of delimiters and you’d like to delete the surrounding delimiters.

That’s something that I sometimes want to do but it gets better. The_cecep shows how to quickly change (foo) to [foo] with delete-pair. That’s something that I want to do less frequently than simply deleting the delimiters but it’s still useful.

Take a look at the_cecep’s post for some more examples and a few details. He also recommends that because delete-pair is unbound you should bind it to Ctrl+Meta+z, which he thinks of as “zap pair”. That seems like a good suggestion to me.

There’s a couple of things worth noting:

• Although the post doesn’t make it clear, you don’t need to select the expression if you just want to delete the delimiters.
• You can set delete-pair-blink-delay to 0 to disable the delay if you don’t want it. The default is 1 second so you should at least set it to a smaller value as the_cecep suggests.

I’m really happy to learn about delete-pair. It’s not something I’m going to use every day but I will use it often enough to internalize it.

A couple of weeks ago, I wrote about piping Eshell output to a buffer. It’s a cute trick but it only works in Eshell. It turns out you can do better.

iLemming has a video on piping in and out of an Emacs buffer even in a normal shell. He begins by showing how to accomplish input redirection within Eshell. That’s not supported by Eshell itself so it requires a supporting eshell function—that iLemming calls b​—to work.

The real juice of the video is making this work in a normal—that is, non-Eshell— shell. That requires another function, mxp, this time a shell script. If you watch the video or follow the mxp link, you’ll see several examples of mxp in use. It’s really quite flexible.

All of this clever and the code is worth taking a look at to see how you might do this type of thing. Still, I don’t see how I would use this capability. I could probably make up some fake application for it but it’s hard to imagine any realistic use. Of course, that’s probably due to my lack of imagination and I’m sure some of you will jump in to educate me.

Update [2025-11-07 Fri 10:49]: Ag Ibragimov notes in the comments that he’s moved the project because of a naming conflict. The new GitHub repository is here.

It’s a lazy Sunday and there’s nothing much going on in the Internet to interest Irreal or its readers so I’m offering you this little nugget that popped up this morning. Oil.el is a tiny package that brings the functionality of Oil.nvim to Emacs.

The idea is that you can batch create files in a given directory by simply listing their names, one per line, into the app. When you’re done, simply type Ctrl+c Ctrl+c and the files are created. Or, you can cancel the operation with Ctrl+c Ctrl+k.

It’s not clear to me why this app is as popular as it seems to be—at least in the Vim world. It’s not that there’s anything wrong with the app itself, I just don’t see the need for it, especially given the existence of Dired. Nonetheless, Emacs is all about letting you have it your way so if Oil’s workflow appeals to you, its existence is a good thing.

The package is not (yet?) on Melpa but you can download it directly from GitHub if you’re interested. I’m guessing that this app will be mostly of value to refuges from Vim who are used to its Vim analog. Regardless, it’s there for you if you’re interested.