Irreal

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.

Álvaro Ramírez has a new video up. This one, Bending Emacs 4, demonstrates several ways of batch renaming files. The secret sauce in most of these methods is the ability of the Dired buffer to become writable and have the changes reflected in the underlying file system. Every time I use it, it seems like magic.

Ramírez’s video shows several ways of performing bulk renamings in the Dired environment. Probably the easiest—or the most natural to me—is simply using a keyboard macro. For instance, if you have a directory full of files ending in .org and want them all to end in .txt, you simply start recording a macro, change the first file, move to the next line, and close the macro. Then you can run the macro on the rest of the buffer to rename all the files. After the renaming, all you need do is type C-c C-c to instantiate the changes into the file system.

Ramírez’s favored way of making the changes is to use Magnor Sveen’s wonderful Multiple Cursors package. It’s a bit more flexible than a keyboard macro because you have finer control over which lines will be changed. Once you’ve got the desired files marked, you simple make the change on one and they are all affected.

The video is only 6 minutes, 42 seconds long so it should be easy to fit in. Ramírez even includes a DWIM command line method of renaming the files. The nice thing about using Dired is that you can arrange for Git to be aware of the renaming. Take a look at the video for the details.