Irreal

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.

One of the nice things about Emacs is that when you find yourself performing the same set of steps repeatedly, it’s easy to capture those steps into an Emacs function or even a keyboard macro. If you’re like me, you’ll keep repeating those steps over and over until one day you realize that you really should automate them. Álvaro Ramírez has a video showing a nice example of this: cloning a git repository.

Ramírez begins his video by showing his old procedure. It’s really simple. Capture the URL to the clipboard, change into the target directory, paste the URL into a git clone command on the Eshell command line, execute it, and open the directory in Dired. If there’s a README, open it as the last step. It takes longer to write it down than it does to actually do it.

Still, they’re simple steps and easy to automate, which is what Ramírez did. His solution is nice. He just has to capture the URL and call his function. Everything else, including opening the README file is handled automatically. He has a bit of code to allow choosing the target directory if he doesn’t want to use the current directory. You can check out his code in his GitHub repository. It is, as I say, simple but it’s a nice example of removing friction from your workflow: just let Emacs handle the routine chores.

The video is only 6 minutes, 54 seconds long so you should have no problem finding time for it. It’s interesting and worth a few minutes of your time.

If you’ve been around Irreal for a while you know that we here in the Irreal bunker have never felt the need for a starter kit. A lot of that is probably due to the fact that they weren’t generally available when I moved to Emacs. I just started with an empty config and began adding things—sensible scrolling, C indentation, and a couple of other necessities—right off the bat. Other changes and additions came later.

Those initial changes are instructive. There were, of course, reasonable defaults for all of them, they just weren’t what I wanted and that’s also the problem with starter kits: they have their own idea of the right thing and it may differ from yours.

Still, when you’re starting out it’s nice to have a way of establishing a reasonable initial Emacs environment even if it’s not exactly what you want. If you do that, it’s important, I think, that the starter kit be easily modifiable. A nice example of this is medicated-emacs, a minimal configuration that’s easily adaptable. Take a look. It mostly set’s a few configuration variables and loads a few select packages.

You probably won’t agree with all these choices. I certainly don’t but the thing is, they’re easy to change. The configuration variables were set with the custom package so they’re easy to change if you want to. You may not want all the packages medicated-emacs loads. For instance, I have no need for rust-mode but it doesn’t hurt to have them there in the short term and after you learn a little more about what you’re doing, you can simply remove the package from the config.

If you’re a beginner and think a simple, non-opinionated configuration would be helpful, take a look at medicated-emacs. It will get you going and will be easy to adapt to your evolving needs.