Irreal

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.

As many of you know, your can output to a buffer directly from within Eshell by redirecting the output to a #<buffer ...> structure like this

Welcome to the Emacs shell

~/org/blog $ echo "Hello World!" > #<buffer hello-buffer>

That naming convention may seem weird but it’s exactly how Emacs refers to buffers. As Christian Tietze says in this post about redirecting output to a buffer you can see this by executing the current-buffer command (it’s not an interactive function so you have to call it as (current-buffer) in some Elisp context).

Tietze covers all this in his post but the interesting thing is that he hates having to remember and type the #<buffer ...> structure. I can sympathize. I got it wrong at least once while preparing this post. Tietze has the solution. He wrote a function, new-buffer, that generates a temporary buffer and returns it just as if you had specified it with the buffer notation. Then he can write Hello World! into a temporary buffer like this

Welcome to the Emacs shell

~/org/blog $ echo "Hello World!" > (new-buffer)

That’s a bit easier to remember and less clumsy to type than the #<buffer ...> construct.

Of course, as Tietze says, all this makes sense only if you’re already in Eshell. Otherwise, you can achieve the same result by simply using shell-command or async-shell-command. Regardless, Tietze’s post is interesting and worth a couple minutes of your time.