Irreal

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.

Like most people, I use setq to set user options in my Emacs configuration. It’s the canonical way of setting a variable in just about any Lisp. But, as Bozhidar Batsov says, it’s not always the best way of setting a configuration variable in Emacs. He suggests using setopt instead.

It’s more than just a convention. The setopt macro does a bit more than setq. In particular, it can arrange to call a setter function when you set a configuration variable. This can be useful for checking the prospective value or for performing some system adjustment when a parameter changes.

I’ve known about this for a while but my problem has always been when you need to use setopt instead of setq. Batsov’s recommendation is to use setopt unless the variable is not defined in terms of defcustom. That’s all very well but how do you know which variables are which? The online documentation isn’t much help so the best policy is probably to assume that any variable in your configuration should be set with setopt unless you have reason to believe otherwise.

Batsov says that setopt will work with regular (non-defcustom variables) as well but that it won’t be as efficient as setq. Really, who cares? The setopt macro will almost certainly not be in a loop so any inefficiency won’t matter much. Plus, as I always say, if you’re using Emacs correctly, you won’t be restarting it very often in any event.

Take a look at Batsov’s post to get an idea of the difference between setq and setopt. It probably won’t help you decide which to use but at least you’ll know what each does.

Update [2025-04-07 Mon 13:42]: In the Emacs subreddit, Batsov notes that an easy way to discover which variables are customizable is to check the documentation with describe-variable. Variables that are customizable will have the notation “You can customize this variable.”

Being a basically boring guy, I almost always have a full screen frame with two side-by-side windows for Emacs. For some functions—Magit and Elfeed are examples—I temporarily pop up a single full frame window but the previous window configuration is restored when I finish. Some of you, I know, lead less constrained lives and have more complicated window configurations.

People with these more interesting configurations sometimes want to move their windows around. When you have two side-by-side windows, that’s trivial—basically Ctrl+u Ctrl+x o is all you have to know—but if you have different sized windows stacked both vertically and horizontally, things can get more complicated.

Pranshu has a nice post that describes the problem and what he’s done to address it. The changes won’t appear until Emacs 31 but for those of you with complex window configurations they will surely be welcome.

Take a look at his post to see the sorts of transformations that are possible and the commands that implement them. To tell the truth, they make me dizzy and I’m happy to stay with my simple configuration but as always Emacs is able to adjust to everyone’s needs.