Irreal

I’ve been writing a lot lately about Álvaro Ramírez’s Journelly, an iOS app that I use constantly everyday. It’s a great app that I recommend for everyone. But Ramírez has been writing apps for Emacs and iOS for a long time. A previous iOS app of his that I used and liked—before Journelly largely replaced it—is scr that sort of implements an Emacs ∗scratch∗ buffer on your iPhone or iPad. I’ve also written extensively about his dwim-shell-command package that provides all sorts of command line shortcuts from within Emacs.

All of this is by way of an introduction to Ramírez’s recent post on tricks for using Emacs on macOS. It’s a long post with a plethora of strategies for using Emacs on Macs. He starts off by mentioning that he uses Emacs Plus—available from Homebrew—rather than compiling it from source, as he used to do. I still compile from source but on my next machine I may take the easy route and use Emacs Plus too.

Another thing he mentions is a point I often make: Although he was a GNU/Linux user for many years, he now works primary on macOS but this doesn’t matter because he does almost everything in Emacs or his browser so the he can get away with being pretty much OS agnostic. The true believers will gasp in horror but it’s a truth that many of us have discovered.

As for the tips, they are too numerous to list here. Most people probably won’t like all of them but I’d be surprised if anyone couldn’t find something useful in the post. For my part, I really liked his configuration for long press for accents and Plain Org for iOS. I expect to implement both of these in the near future.

If you use Emacs on macOS you should definitely take a look at Ramírez’s post. You’re sure to find something useful.

iLemming has an interesting post on Hacker News about why younger engineers don’t use Emacs and why they should. You may find the post a bit overwritten but I especially like the ending:

The specialized app user lives in rented apartments; the Emacs devotee walks through an ever-expanding mansion whose rooms rearrange themselves to their thoughts.

That’s a nice metaphor for the Emacs experience. Whatever you need it to be, Emacs will change itself to accommodate you. We usually talk about Emacs as being a clay that we can mold into whatever shape we desire but I like this description better.

Not everybody agrees. Over at the Emacs subreddit there’s a bit of pushback. That’s fine but some responses, like this one, just seem uninformed. You can tell that the commenter doesn’t really know what they’re talking about because they refer to Emacs as “eMacs”. It’s not a big thing but it’s a sure sign that the commenter isn’t really familiar with the subject matter.

All that aside, I really like the metaphor of Emacs being a mansion whose rooms rearrange themselves to suite your needs.

Lately, I written a few posts about Emacs-induced RSI and various strategies for overcoming it. For example, my post on The Best Emacs Keyboard seemed to strike a chord with many Irreal readers. One thing that almost everyone agreed on was that being able to use your thumbs for the modifier keys is a big win and can go a long way toward remediating Emacs pinky.

One strategy for people with serious RSI problems is to adopt the Vim keybings, which largely do away with modifier keys and their attendant RSI problems. Another solution is the ergonomic, split keyboards that make modifier keys accessible with your thumbs. Some of us find it hard to warm up to either of those solutions.

Of course, if you’re working with a laptop you’re pretty much constrained to whatever fixes you can implement in software unless, like MarkB, you’re handy with 3-D printers. Over at the Emacs subreddit, awesomegayguy has a post about a keyboard that sort of splits the difference. By that, I mean that it does in hardware the sort of thing you can do by remapping Emacs keys. That has the advantage that the revised bindings are available systemwide, not just in Emacs.

There’s nothing earthshattering about this, of course, it’s just another datum in the encyclopedia of Emacs-friendly keyboards. Still, it’s a nice solution for those people who want a hardware solution but don’t want a split keyboard or any of the other nontraditional keyboards. If you’re interested in this sort of thng, take a look at awesomegayguy’s post.

Lynn Leichtle over at Lynn has an interesting post on using Emacs as a Guix file manager. Almost all of my work these days takes place in the Apple milieu so, of course, I’m not a Guix user and can’t speak with even pretend authority about it. Still, Lynn’s post is easy enough to understand. She does most of her work in Emacs and finds that she has no need for a file manager. Emacs handles all that for her. But occasionally, for reasons you can read about at her post, she wants to click on a directory and have it open in Emacs dired.

It turns out that Guix can do this for you fairly easily. See her post for the details if you have a similar need.

Lynn’s post made me realize that I have actually embraced the old joke about Emacs being an OS. Of course I don’t need a file manager; that’s what Dired is for. And if I open a directory in Emacs, I’m popped right into a Dired buffer for that directory.

Furthermore, I don’t really need anything like Guix either. I hardly ever load third party packages—other than Emacs, of course—and when I do I usually get them from the app store, or Homebrew both of which take care of all the things Guix would do. When I do need a third party application, it’s almost always an Emacs package and, of course, Emacs handles all that pretty much seamlessly.

Given all that, it’s hard to avoid the conclusion that Emacs really has become my OS. Basically, everything I do, I do from within Emacs. You could call that obsessive but I call it simplifying my life.

Kay Lack has an interesting video on the ed editor. As the cognoscenti know, ed is the standard Unix editor, even though virtually no one uses it anymore. The reason for that is that ed was designed for teletypewriters and is therefore line oriented. That means that from the modern perspective, ed is user hostile. You can’t address individual characters or easily change the content of a line. Almost all operations work at the line level.

Of course, all this makes sense in the context of TTYs. They were slow—really slow—as they typed out what we today would consider the display. It just didn’t make sense to type out a multiline program. make a change, and type it out again. Indeed, the primary concern was typng as little as possible to prevent wasting time.

Lack explains all this and take us through the history of the editor. My only complaint is that she repeatedly refers to it as “ed” rather than “E D”, it’s actual name. Of course, hardly anyone remembers this anymore so it’s a small thing.

If you’re interested in the history of ed and why it’s the way it’s is, take a look at Lack’s video.

There still exists the notion that serious developers should know ed in case they experience boot problems, need to change a configuration file, but their normal editor isn’t available. Ed lives in /bin so it will almost always be available unless there are serious hardware problems. That may still be true in Linux or *BSD based systems but probably isn’t in macOS.

Nonetheless, I still maintain a reasonable facility with ed just in case. It is, after all, the standard Unix editor.

If you’re one of those people who obsess about making every Emacs operation as fast as possible, James Dyer has quick tip for you. Dyer uses Dired a lot and one of his common operations is to search for a file in a Dired buffer using isearch-forward and then open it. Of course, he wants to make this operation as efficient as possible so he objects to the fact that he has to type Return twice: once to terminate the search and then again to open the file at point.

Dyer’s tip is a way of completing the search/open operation with a single return. He does this with a bit of advice to the isearch-exit function. Check out his post for the details.

Dyer admits that this is a small thing and even makes a back of the envelope calculation of how long it will take him to recoup the time he spent implementing the solution. Of course, sometimes it’s the journey and what we learn along the way that’s important and this is probably one of those times.

Regardless, if you find yourself often searching for and opening a file in Dired, you may find Dyer’s tip useful. At least you will if you care about saving a keystroke with each operation.

When the Eagles disbanded after a particularly contentious Long Beach concert where Glenn Frey and Don Felder almost came to blows, Don Henley quipped that the band would get back together when Hell freezes over. Fourteen years later the band did reunite and released their new album, Hell Freezes Over.

I was reminded of that when I read Bozhidar Batsov’s latest post on Rediscovering Vim. Most people don’t know that, like me, Batsov used Vim early in his career. He apparently didn’t stay with Vim too long because of its really hideous extension language. I was less interested in customizing my editor back then and stayed with Vim for many years.

Batsov isn’t, of course, abandoning Emacs. He just wants to “rediscover” Vim and see what he can learn from it. He started out with Neovim, which, apparently, most developers in the Vi camp are using now. But he dropped back to Vim so that he could develop his own configuration just as he had with Emacs.

Batsov likes the way Vim has the notion of “text object” and a uniform way of dealing with those objects. As I’ve said before, that’s what makes it so easy to learn and use the Vim key sequences. I don’t really miss Vim but if I did, it would be that aspect that I’d miss the most.

As I’ve also said before, I have significant muscle memory problems trying to use more than a single editor so we here at the Irreal bunker won’t be recreating Batsov’s experiment. And, really, muscle memory notwithstanding, I have no desire to. I’m perfectly happy with Emacs and indulge what little desire I have to tinker with editors to playing with my Emacs configuration.