Irreal

Seth Godin has an interesting post on the use and design of tools. His thesis is that some tools, such as a hammer, are immediately accessible to the casual user. Even experienced hammer users aren’t going to be significantly more efficient in their use.

The tools that you and I use—modern tools as Godin puts it—aren’t like that. They’re more complicated and very often difficult for the casual user to use effectively. Sadly, says Godin, these casual users don’t bother to learn how to use these tools well. They take the attitude that they’re too busy to waste time on learning, let alone mastering, their tools. Meanwhile those who do master these tools can be orders of magnitude more efficient with them.

So why does this post have the “Emacs” tag? It’s not a mystery. One of the most frequent complaints that I’ve been seeing against Emacs is that it’s too hard to learn and that, after all, real people have jobs to do and can’t afford to spend time learning things. Left unstated is how all those Emacs users, many of whom have produced truly astounding software, managed to learn Emacs.

Over and over again you see phrases like “VS Code just works out of the box.” That’s great for the casual user “too busy” to master difficult tools but failing to master your tools creates a debt that will come due, probably at a most inconvenient time.

As Godin puts it,

Don’t hold the hammer at the wrong end. And insist on software that’s worth the time it takes to learn.

Most important, once you find software that’s worth the time to learn, learn it.

None of this is to say that you must, or even should, use Emacs. Only that whatever editor you choose, take the time to learn it well.

A week and a half ago, Bozhidar Batsov stirred up a storm by claiming that Emacs startup time doesn’t matter. There was much foaming at the mouth but I agreed with Batsov: Emacs startup time hardly every matters. When it does, it is in very special circumstances that, happily, most of us never experience.

At the end of my post on the matter, I said that if your Emacs startup time is lengthy, it probably indicates a problem with your configuration. Batsov apparently believes the same and in a new post offers some advice for addressing that problem.

He frames his discussion in terms of the use-package macro that most people use. The secret, he says, is to delay loading packages until they are needed. That makes sense because loading a single package won’t take long but loading, say, a hundred may add significant time to your init time. By deferring the loading, you speed up Emacs’ startup time at the cost of adding a tiny delay later when you first actually need a package.

Batsov’s suggestions are a bit complex but the TL;DR is to avoid the :preface, :init. and :config keywords. You should definitely read his post for the details. Ironically, he doesn’t follow his own advice because, as he says, Emacs startup time doesn’t matter.

Joshua Blais has an interesting post that looks at the idea of using Emacs for everything. That’s a familiar meme for us Emacsers, of course, but you don’t often see a careful, considered examination of the idea. Blais is an Emacs user so his post is, naturally, supportive of the idea but he does try to give both sides of the issue.

Blais’ main argument is built around the flow concept. Interrupting a knowledge worker’s flow can have devastating effects on their productivity. These interruptions include context switches and one study suggests that context switching and multitasking takes up around 60% of our working time. That seems high to me but whatever the value, it’s certainly significant.

One of the virtues of Emacs is that virtually all your text based tasks can be done in Emacs. That’s significant because the editor provides a uniform interface to all those tasks. Indeed, you can even slip it into other apps with packages like Emacs Everywhere that allow you to bring up an Emacs window to edit some app’s text area. For example, I use it with iMessage so that I can compose my texts in Emacs.

The advantage to doing most things in Emacs is that you avoid context switches and can better stay in the flow. A secondary benefit, as least for me, is that it provides a single set of muscle memories to deal with. As I’ve said before, I do better with a single set of keybindings so folding everything possible into Emacs is a win for me.

Blais also considers and dismisses the argument that Emacs takes so long to learn that you never regain the time “lost” to learning it. Even a few seconds thought is enough to recognize that idea for the silliness it is but Blais makes the point that if you aren’t using Emacs you’re still spending time learning other utilities that Emacs would otherwise handle. I know this first hand. Before I came to Emacs I was a long time command line user and spent years learning to use it effectively. Now I rarely use the command line; everything I need to do I can do from within Emacs.

Blais’ post is well worth a few minutes of your time whether or not you’re an Emacs user. Take a look.

Joe Marsahll has been blogging up a storm lately. One of his latest posts is a sort of personal history of Emacs and its relationship to Lisp. When Marshall started as an undergraduate, he was using the line oriented editor TECO. If you think your experience with an editor is difficult, read his description of what it was like to use TECO.

Soon he was directed to Vi and a whole new world was opened to him. He no longer had to work in the blind but could actually see what he was doing. Later, when he moved to MIT he was introduced to Lisp and various early incarnations of what we now think of as “Emacs”.

Emacs, of course, began life as a set of macros for TECO so, in a sense, Marshall revisited TECO when he started working at the MIT AI lab. but the Lisp Machines that were developed in the AI lab had their own Emacs clone integrated into the system. In his career he has used a wide variety of Emacs-like editors but like all of us he’s using GNU Emacs these days.

One of the things Marshall talks about is using Sly with Emacs to recreate his experiences on the Lisp Machine. Sly, he says, pretty much recreates the interface that you had using ZWEI—an early version of Emacs—on a Lisp Machine. I’m still using Slime for my Lisp coding but, as I have written many times, I have a long standing urge to work on a Lisp Machine so I may give Sly a try if only to get closer to the Lisp Machine experience.