Irreal

Over at the Emacs subreddit, EachDaySameAsLast asks the perennial question: why does Emacs take so long to load. Actually, his question is, “Why do people say Emacs takes so long to load?” He has, he says, been using Emacs since its TECO days and has never, even in the old days, experienced overly long load times. To be sure, his configuration file is relatively short—about 100 lines—but Emacs loads for him in under 2 seconds.

Of course, as many of us have been saying and saying, none of that matters. For almost every user, Emacs shouldn’t be started very often: once a day at most, once every week or month typically.

As usual, the interesting part of the post is the comments. Almost everyone agrees: the load times don’t matter but if you use use-package and the defer option judiciously, your load time can be small too.

I’m beginning to feel as if I’m codependent with those people claiming that Emacs takes too long to load. I should probably just stop writing about it. Of course, it won’t matter. People—many of whom don’t even use Emacs—will keep repeating it.

But let me just repeat, with Batsov, that Emacs load time doesn’t matter. It really doesn’t.

Joar Von Arndt has an interesting post on a subject that many Emacs users obsess about: how to bring Web browser functionality into Emacs. As, I’ve said many times, virtually all my tube time is either in Emacs or Safari. I would, of course, like to get that down to just Emacs. To be sure, I do use some other apps but my time with them is basically in the noise. Almost everything I do on the computer involves Emacs or the browser.

Von Arndt looks at eww, w3m, Xwidgets, and EAF. He discusses the pros and cons of each. He appears to think that eww—with some customization—is the best solution.

My solution is to use Xwidgets for rendering Email posts that need it and for my RSS feed via Elfeed. My email client, mu4e, makes it easy to switch between text and HTML rendered displays. It is, in a way, the best of both worlds. I can read most of my emails in plain text, as the elders decreed, but can switch to an HTML rendered display when I need to.

I use elfeed-webkit to display my RSS feed with Elfeed. It brings up each entry in a browser like display and, of course, can be easily be toggled on and off. It’s a bit fragile, as Von Arndt says, but it easier than invoking the brower for each entry.

The sad news is that there still isn’t a good solution but what solutions there are are getting better. Perhaps we will soon have a way of bringing the final major holdout into the Emacs fold.

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.