Irreal

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.

In the old days, World Clocks were a sort of curiosity. There wasn’t a lot of need for them because most folks communicated with distant friends and colleagues with snail mail and later, I suppose, with email. In any event you didn’t need to know what time it was at the destination unless you were making an almost certainly hideously expensive phone call.

Now, of course, you can instantly message someone—or even call them in many circumstances—with no charge and it’s best to know that it’s not 3 AM where they are. That’s why, today, a world clock is almost a necessity. You can always ask the Duck or whatever you use but if you’re communicating with several people, it’s convenient to have your own world clock with all the appropriate times.

Emacs, as usual, has us covered. There’s the world-clock command that gives you the current time in a few cities but if you’re parochial like me, knowing what time it is in London doesn’t help much if I want to talk to someone in, say Glasgow. Maybe it’s the same time zone; maybe it isn’t. I have no idea. Like most things in Emacs, the cities displayed are configurable but it’d be pretty inconvenient to add cities on the fly.

The other problem is that only the current time is displayed. What if you’re trying to set up a meeting and want to know what time it will be sometime in the future? It would be nice to be able to adjust both the cities and the time displayed.

Álvaro Ramírez had these problems and being Ramírez he wrote a package that solves both of them. You can add cities on the fly and adjust the base time forward and backward. Right now, the package is only on GitHub so you have to get it from his GitHub repository but he’ll probably put it up on Melpa eventually.

This is a great package that makes figuring out what time it is/will be/was in some arbitrary place in the world easy. Take a look. It may be something you didn’t realize you needed.

It’s Sunday and nobody—especially me—feels like working so here’s a short interlude while we’re waiting for the new week to begin. The subject of today’s post falls in the broad category of what could be called “mobile Emacs”.

Most of us have wished for a way to take Emacs with us when we’re out and about. Certainly, no one would want to do any serious editing on a smart phone—although Po Lu has produced an Android port—but it’s not hard to imagine using it on an iPad or other powerful tablet.

Then there’s this guy who literally wears his computer complete with a heads up display so that he always has access to his Emacs. When I saw the video, I immediately thought of Neal Stephenson’s gargoyles from Snow Crash. It’s the exact same idea: people wearing computers—and looking odd—so they can stay continuously connected to the metaverse or what we in this world call “the net”.

As much as some of us would like to be permanently connected, I doubt that many of us are prepared to embrace the solution suggested in the video. Of course, I could be wrong and it’s just what people are looking for. Let us know what you think.

Over at the Emacs subredit, iinnssdd says he was looking for a guide to speed up Emacs but couldn’t find one. Therefore, he put together his own. This is more than the usual “how to make Emacs load faster” article, which we all know are silly and a waste of time. Although there are some suggestions for making Emacs load faster, the useful parts are how to make Emacs run faster once it’s loaded.

Some of that are compile time options when building Emacs from source. Iinnssdd’s particular options may or may not apply to your situation but they’re worth taking a look at. Another obvious strategy is to make sure that you have native compilation enabled. Iinnssdd has some suggestions for that.

A couple of specific recommendations are applicable to many of us. They’re both pretty simple and easy to implement. The first is a hook function to the find-file function that looks at how many lines the function has and turns off display-lne-numbers-mode when there are more than 1000 lines. It’s easy to see why this would speed things up on large files.

The second speedup is similar. It’s another find-file hook that looks for C files that have more than 1000 lines and turns on simpc-mode when it finds one. Simpc performs minimal syntax highlighting and indentation and, according to its author, is much faster than c-mode, c++-mode, cc-mode, and so on.

Even though I don’t have native compilation enabled on my older MacBook (2019), I still don’t find Emacs insufferably slow. That could be one of the benefits of having grown up with much older computers that were really slow. Regardless, if you’re intent on squeezing every bit of performance from Emacs, Iinnssdd’s post may give you some ideas.