Irreal

I do a lot of my writing on my couch with my MacBook on my lap. That provides a less than optimal typing environment so I frequently mistype a command and end up magically transported to another place and time. Sometimes it’s just to another place in my current file but often it’s to another file altogether.

Apparently, I not the only one who suffers from this. Chris Maiorana, who writes for a living and uses Emacs to do so, has the same problem. He asks, wouldn’t be nice to be able to have a “back key” that would take you back to where you were before you fat fingered some command and were transported into the nether regions.

Maiorana notes that Emacs pretty much has this out of this box with push-mark that stores your location before many location moving commands. It stores your current location in the “mark ring” from which you can pop the location to return to the place where the mark was pushed.

But, asks Maiorana, what if you want to go forward too? It’s not to hard to imagine situations where you want to go back and forward between locations during your editing. It turns out that you can do that too with the help of the backard-forward package. Maiorana has a few more details in his post so take a look if you’re interested.

If you don’t want to add another package, you can simply use Ctrl+u Ctrl+Space to pop the last saved location and go to it.

I use Ctrl+u Ctrl+Space all the time but do forget to use it when I inadvertently find myself in an unexpected place. Whether you choose to install the backward-forward package or simply rely of popping the mark, it’s good to be aware of how simple it is to recover.

Note: Sorry, I got caught up with life and completely forgot to publish this this morning.

If you’re a Flycheck or Flymake user and like eye candy, you might enjoy this new package from Mikael Konradsson. It’s a nice looking overlay for Flymake and Flycheck. There’s a couple of screen shots at the link that show what it looks like.

There’s a lot more information at the project’s GitHub repository. There are more screenshots and a more comprehensive explanation of what it does and how it works. As I said, there’s a lot of information at GitHub so you should definitely take a look at that if your interested but here’s a list of it’s features taken from the repository:

1. Nice looking, customizable overlays for error display that are theme aware
2. Errors, Warnings, and Info messages are distinguished by different styles
3. Realtime updates while editing
4. Smart position and formatting of messages
5. Efficient overlay management
6. Markdown-style syntax highlighting in messages

The package is available from Melpa so it’s easy to install if you’d like to try it.

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.