Irreal

If you’re a regular Irreal reader, you’ll be familiar with Charles Choi. He often has useful takes on Emacs matters and, of course, he’s the author of the excellent Casual Suite that helps you use all the arcane features of many familiar Emacs commands.

Early on in his Emacs career, Choi tried Eshell but it didn’t take. That’s because, he says, he was expecting it to act like a normal shell, which it most certainly doesn’t. Now Choi has a post that offers a second take on Eshell. It’s a take informed by Choi’s many years of using Emacs and learning to appreciate Eshell.

Choi says that you should begin by thinking of Eshell as offering an Emacs REPL that can easily reference the command line utilities traditionally accessed through a conventional shell. He gives several examples of how that works.

He also mentions something that I’ve noticed too. He now does most of the things he used to do in a conventional shell through Emacs functionality like Dired and Magit. He has a table in his post that compares various shell tasks with their corresponding Eshell equivalents.

I try to use Eshell whenever I need a shell but I haven’t internalized the Eshell way as Choi has. Reading his post has inspired me to do better and try to use Eshell more often. One way to do that is to use Eshell instead of using a key shortcut or Meta+x to invoke Emacs functions such as Dired.

If you’d like to improve your Emacs game, take a look at Choi’s post. There’s a lot of meat in it.

There are many, many posts on Irreal about the journey that people make from the hinterlands to Emacs. This post is about the journey from uber-distributions like Spacemacs and Doom to plain old vanilla Emacs. Irreal doesn’t hold any position, political or otherwise, on what distribution you should use. We’re content to let each user find his or her own Nirvana.

Still, it’s true that many converts come first to Doom or Spacemacs because they find it a bit more familiar and comfortable. Plenty of those people find a permanent home in one of those distributions and live happily ever after. Others, though, still hear the siren song of traditional Emacs and eventually complete their journey by adopting vanilla Emacs.

Donovan Ratefison has a post that recounts his own journey. He has a nice metaphor involving drinking tea. When he first started drinking tea he liked it with lots of sugar. Eventually he discovered that the sugar was masking the true taste and aroma of the tea. The raw tea was, perhaps, an acquired taste but once acquired it opened up a whole new world or tastes and sensations to him.

So it was with Emacs. Ratefison tried both Spacemacs and Doom and liked them both but vanilla Emacs kept calling to him. He like may others decided that he wanted a minimal configuration where he understood everything and there were no packages that he didn’t actually need and use.

He includes a copy of his init.el and it is, indeed, simple. He loads only a few packages. He will probably find the need for additional packages as his Emacs use matures. That, at least, has been my experience but it seems that he has found, as with tea, that unsweetened Emacs is better.

Update [2025-07-07 Mon 18:55]: Added link to Ratefison’s post. Thanks—again—to Sacha.

Flandrew likes Org mode but he wanted to improve his workflow with it a bit. So he wrote some code that he called Fold and Focus—Focused Navigation. The idea was that when in Org mode a single key would move to the next or previous subtree, position that subtree at the same place on the screen, and have everything else folded so that he could concentrate on the current subtree.

That worked out pretty well but after a while wanted to bring the same sort of functionality to Elisp buffers, which he did. Recently, while working in a Markdown buffer, he automatically tried to navigate in the same way but, of course, it didn’t work. So he did the natural thing and ported focused navigation to work in Markdown buffers.

I don’t use Markdown so I have no use for this functionality but it seems like a really useful addition to your toolkit if you do. Take a look at flandrew’s posts. He has animations that show how it works in all three environments. If the project seems interesting to you, take a look at the project page.

Today (Saturday) appears to be a slow day on the technical Internet or perhaps everyone is hiding out from the AI apocalypse. Whatever the reason, I can’t find anything to write about that’s up to the refined standards of Irreal readers.

I offer, therefore, this short post on a niche problem that most of you probably don’t have but that may be useful to those that do. If you’re an Eshell user you may or may not know that if you repeatedly try to run a command that doesn’t exist, Eshell will ask you if you want to set an alias. Over at the Emacs subreddit, Both_Confidence_4147 complains about this and asks how to stop it.

Presumably, Eshell thinks you’re repeatedly mistyping the command name—as in the old time common error or typing “moer” for “more” and similar errors—and is offering you a way to avoid the error going forward. Eshell will ask you for an alias after 3 failed commands but, of course, this is configurable. You can also arrange to disable the prompt completely as explained in this comment to Both_Confidence_4147’s post.

Again, this is a niche problem unless, of course, you’re the own who’s experiencing it. If you are, now you know how to fix things.

Because I know you guys never stop jonesing for another episode of the endless debate on Emacs startup time, here’s yet another post to feed your addiction. Over at the Emacs subreddit, prothtuahel complains that Emacs is taking 3 seconds to load 412 packages¹ when all he wanted to do was add a TODO to a file.

There’s so much to say. First, why are you restarting Emacs for each file you want to edit? I know it can be disorienting for new users but when you’re using Emacs, you should leave it running all the time and not restart it every time you want to edit a file.

Second, if you must restart it for each file, start Emacs in server mode and use emacsclient to invoke it for each editing session. Emacsclient will start instantly because Emacs is already waiting in the background. But really, see the first point.

Third, you’re complaining about taking 3 seconds to load 412 packages? That’s actually pretty fast, but see the first and second points.

The comments mostly concentrate on the three points above but, of course, someone points out that you can speed things up with lazy loading. To me, the most cogent argument is that who cares?. If, as you should, you only load Emacs a few times a month or year, who cares how long it takes to load? I always get pushback when I write that but unless you’re one of the few people with special needs that require starting Emacs often, it remains true.

Over at the Emacs subreddit, floofcode asks those who moved from Vim to Emacs to tell their stories. On the one hand, it’s pretty much what you’d expect. The majority of the commenters said it was either Org mode or Magit (or both) that convinced them to move.

The second most popular response was that Evil mode—with or without Doom or Spacemacs—was the selling point. Those users felt that they got all the familiar benefits of Vim along with the power of Emacs.

For me, the most interesting responses where from those users who said that they found Emacs to be faster and easier to use than Vim. That’s a bit of a surprise. It’s received wisdom that Vim is faster and easier to use than Emacs, yet these users found just the opposite.

Oddly, none of these answers apply to me. I migrated from Vim to Emacs before the time of Org mode or Magit. And, although I was a long time Vi/Vim user, I didn’t embrace Evil mode but jumped right into the conventional Emacs milieu.

So what was the attraction? At this point, I don’t really remember. I think it was about the time I started using Lisp and Scheme seriously so it seemed like the Lisp based Emacs was a natural choice. As I’ve written before, I’d made tentative attempts to move to Emacs before but one silly thing or another always stopped me. Suddenly, the universe and I were ready and I moved to Emacs without looking back.

A quick post today.

Charles Choi has just released another app in his Casual suite. This time it’s for the man and help modes. We all use these all the time, of course, but there are plenty of obscure bindings that most of us don’t remember. As usual Choi’s app helps with that by providing easily invoked menus.

Along the way, Choi also tells us about some little known features of man and help mode. For instance, when in man mode, you can press Return when the point is on another command and Emacs will open the man page for that command whether or not it’s an actual link. There are a couple of other nice facts like that so be sure to take a look at Choi’s post.

As I always say when I do one these posts, Choi’s Casual suite just keeps getting better and better and since you can use the same binding to invoke the appropriate menu, they’re easy to use and well worth installing.

One of Emacs’ really nice features is TRAMP. It allows you to edit files on a remote system and otherwise interact with that system as if you were working on your local machine. The problem with it is that it can sometimes be slow, even unusably so.

Troy Hinckley over at Core Dumped has a very interesting post on making TRAMP faster. Oddly, almost everything he does is merely adjusting settings. He writes a bit of code to implement caching but even that is minimal.

Hinckley’s post is long and complicated because he explains what he’s doing and why it works. He’s spent a lot of time profiling and researching how TRAMP works. That’s nice because it means that he’s not just trying things to see if they work.

This is a short post because rather than simply listing the things that Hinckley did without explaining the reasons for them, I’m going to send you over to his post to get the full story. If you’ve tried using TRAMP but found it too slow for your particular workflow, take a look at Hinckley’s post. His changes are easy to implement so you can try them out without a lot of effort.

Happily, my use of TRAMP mostly involves the local network or remotes connected with a high speed network so I usually don’t experience these slowdowns. Even so, it’s probably worth implementing his changes.