Irreal

If you’re using Magit on macOS, here’s a tip that will either improve your life considerably or not affect you at all. The tip is from Greg Newman who says that it reduced his commit time from about 4 seconds to less than a second.

The secret? It turns out to be simply specifying a pointer to the git executable like this:

(use-package magit
  :bind ("C-x g" . magit-status)
  :custom
  (magit-git-executable "/opt/homebrew/bin/git"))

Of course, after the excitement dies down, you start thinking, “Wait! What? That can’t be right.” Well, what can’t be right is that it’s taking 3 seconds to find the git executable by searching the PATH variable. What is happening then?

It turns out that Apple provides a copy of git that it puts in /usr/bin/ but if you’re using Homebrew and loaded git with it, the executable lives in another place. In Newman’s case, that place is /opt/homebrew/bin/. In my case, it’s in another place but the same thing happens: there are two versions of git in your file system and unless you’ve performed surgery on your PATH variable, Emacs will probably find the older version provided by Apple.

What’s really going on here, it seems, is that without some further action on your part, Emacs—or more precisely, Magit— may be finding the older, presumably slower, version of git. You might wonder why someone would load git from Homebrew. As I recall, the version of git provided by Apple wasn’t quite working correctly and, in any event, you might want the latest version with all its improvements and bug fixes.

Regardless, if Magit seems slow you should:

1. Make sure you have the latest version of git loaded from Homebrew or elsewhere
2. Ensure that Magit finds that git either by adjusting your PATH variable or setting an explicit path as Newman does.

James Dyer has announced a new package called Simply Annotate. It is, as the name suggests, a package to make annotations to a file with the feature that the original file is not modified. There are, of course, as Dyer says plenty of packages that do this sort of thing but he wanted a light weight package that specifically met his needs and preferences.

Dyer has a list of those preferences, which you can read at his post or you can take a look at the user manual. Regardless, it appears to have some nice features. Dyer has an animation that shows how the system works. The package is available on Melpa or directly from its GitHub page. There’s plenty of information on Dyer’s post, which appears to be essentially the same as the GitHub README.

I’ve tried very hard in the past to warm up to applications like this. After all, they make perfect sense: you can make personal notes concerning the file content without altering the file itself. I spent a certain amount of time making such notes but then never—ever—actually read them. I reluctantly concluded that such things were not for me. But they may be just right for you so you should definitely take a look.

Over at the Emacs subreddit, SecretTraining4082 asks long term vanilla Emacs users how their hands are holding up. You’d be forgiven if you think the answer is “terrible”. After all, it’s received wisdom that Emacs’ default key bindings are particularly hard on your hands and inevitably lead to Emacs pinkie or some other form of RSI. Certainly there are serious and well informed people like Eric Fraga who say that RSI caused them to move to Evil mode.

I’ve always taken these people at their word, of course, but, even more, have generalized their experience to the larger Emacs user population, even though I have never suffered from any RSI problems despite years of Emacs use and even more years of constant keyboard use.

I was, therefore, a bit surprised at the answers to SecretTraining4082’s question. Almost every responder said that they didn’t suffer any significant RSI problems despite years of vanilla Emacs use. Many of them attributed this to turning the Caps Lock key into another Ctrl key. I’ve been doing this for as long as I can remember—long before I was an Emacs user—so perhaps that helps explain my lack of RSI problems.

Some of the commenters recommended the usual things like split/ergonomic keyboards but it’s surprising how many said they have been using vanilla Emacs for 30 or 40 years without any problems and without doing anything special other than making Caps Lock into another Ctrl key.

There are, for sure, people who do suffer RSI problems from the default Emacs keybindings but I was surprised at the number of people who said they didn’t. It appears that the idea that Emacs keybindings inevitably lead to RSI may be another trope used by Emacs haters to justify their animus.

After yesterdays post about Charles Choi’s second take on Eshell, I discovered that Choi’s post was part of a collection by Christian Tietze on a second take on various Emacs topics. Tietze himself had a post on Emacs on Second Try.

His story is not at all like mine. He first use of Emacs was under duress as part of a university course. He used it because it was required but left it behind as soon as he could. He was pretty happy using it with the text based terminals at school but once he got his first Mac he abandoned it completely.

Over the years, he learned about things like the package system and compiling from within Emacs. He was also attracted to the configurability of Emacs. He liked some of the Xah Lee’s bindings and was able to incorporate them into his Emacs configuration.

Eventually, of course, Tietze became a convert. His story and mine are alike in one respect: we both initially resisted Emacs and spent some time overcoming that resistance. And, of course, we both became committed Emacs users.

It is, really, a common story. Many of today’s zealous Emacs users took some time to adopt it. For some, like me, it took several tries before it took.

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.