Irreal

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.

Bozhidar Batsov has a post that claims something I’ve often said: Emacs startup time doesn’t matter. No one is saying that your editor taking 30 seconds to start is acceptable but by and large the people you see worrying about startup times are obsessing over sub-second differences. That is, differences that are virtually imperceptible to a human at the keyboard.

Batsov and I say that if you’re using Emacs correctly, you hardly ever restart it. Unlike, say, Vim, you shouldn’t start a new Emacs session for each file you want to edit. When I switched from Vim to Emacs, this was one of the hardest things to get used to. Even if you do want to invoke Emacs for each file, you can simply use Emacsclient and get near instantaneous response.

Judging from the comments on reddit, you’d think Batsov had resurrected Swift’s Modest Proposal. He was accused of being arrogant and not understanding how “real” people use Emacs. If you know anything about Batsov, you’ll find that an amusing notion.

Sure, people do use Emacs in different ways and for different reasons. One commenter, for example, says he develops packages and often has to restart Emacs. John Wiegley does the same but he was a separate Emacs that starts quickly to deal with that: when you’re testing a package you probably want something approaching Emacs -Q anyway.

The TL;DR is that for almost everyone, Emacs startup time really doesn’t matter. I restart Emacs once a week when I upgrade my packages. Batsov says that he goes months without a restart. Even if Emacs did take 30 seconds to start, why would we care. One commenter complains that he has to restart Emacs every morning and, therefore, startup time really does matter. Sorry, but that’s just silly. If you have to spend 5 seconds—or even 30 seconds—starting Emacs in the morning, who cares?

And, by the way, if Emacs really is taking more than a few seconds to start, it probably means that there’s something wrong with your configuration. Mine has plenty of packages, hasn’t been refactored since I started almost 20 years ago, and it still starts within a couple of seconds. It’s hard to get a hard number because it stops to ask me for a password for my .authinfo file. I’m inclined to think of it like booting my machine: it’s not instantaneous but I don’t do it very often.