Irreal

Because I know you guys never stop jonesing for another episode of the endless debate on Emacs startup time, here’s yet another post to feed your addiction. Over at the Emacs subreddit, prothtuahel complains that Emacs is taking 3 seconds to load 412 packages¹ when all he wanted to do was add a TODO to a file.

There’s so much to say. First, why are you restarting Emacs for each file you want to edit? I know it can be disorienting for new users but when you’re using Emacs, you should leave it running all the time and not restart it every time you want to edit a file.

Second, if you must restart it for each file, start Emacs in server mode and use emacsclient to invoke it for each editing session. Emacsclient will start instantly because Emacs is already waiting in the background. But really, see the first point.

Third, you’re complaining about taking 3 seconds to load 412 packages? That’s actually pretty fast, but see the first and second points.

The comments mostly concentrate on the three points above but, of course, someone points out that you can speed things up with lazy loading. To me, the most cogent argument is that who cares?. If, as you should, you only load Emacs a few times a month or year, who cares how long it takes to load? I always get pushback when I write that but unless you’re one of the few people with special needs that require starting Emacs often, it remains true.

Over at the Emacs subreddit, floofcode asks those who moved from Vim to Emacs to tell their stories. On the one hand, it’s pretty much what you’d expect. The majority of the commenters said it was either Org mode or Magit (or both) that convinced them to move.

The second most popular response was that Evil mode—with or without Doom or Spacemacs—was the selling point. Those users felt that they got all the familiar benefits of Vim along with the power of Emacs.

For me, the most interesting responses where from those users who said that they found Emacs to be faster and easier to use than Vim. That’s a bit of a surprise. It’s received wisdom that Vim is faster and easier to use than Emacs, yet these users found just the opposite.

Oddly, none of these answers apply to me. I migrated from Vim to Emacs before the time of Org mode or Magit. And, although I was a long time Vi/Vim user, I didn’t embrace Evil mode but jumped right into the conventional Emacs milieu.

So what was the attraction? At this point, I don’t really remember. I think it was about the time I started using Lisp and Scheme seriously so it seemed like the Lisp based Emacs was a natural choice. As I’ve written before, I’d made tentative attempts to move to Emacs before but one silly thing or another always stopped me. Suddenly, the universe and I were ready and I moved to Emacs without looking back.

A quick post today.

Charles Choi has just released another app in his Casual suite. This time it’s for the man and help modes. We all use these all the time, of course, but there are plenty of obscure bindings that most of us don’t remember. As usual Choi’s app helps with that by providing easily invoked menus.

Along the way, Choi also tells us about some little known features of man and help mode. For instance, when in man mode, you can press Return when the point is on another command and Emacs will open the man page for that command whether or not it’s an actual link. There are a couple of other nice facts like that so be sure to take a look at Choi’s post.

As I always say when I do one these posts, Choi’s Casual suite just keeps getting better and better and since you can use the same binding to invoke the appropriate menu, they’re easy to use and well worth installing.

One of Emacs’ really nice features is TRAMP. It allows you to edit files on a remote system and otherwise interact with that system as if you were working on your local machine. The problem with it is that it can sometimes be slow, even unusably so.

Troy Hinckley over at Core Dumped has a very interesting post on making TRAMP faster. Oddly, almost everything he does is merely adjusting settings. He writes a bit of code to implement caching but even that is minimal.

Hinckley’s post is long and complicated because he explains what he’s doing and why it works. He’s spent a lot of time profiling and researching how TRAMP works. That’s nice because it means that he’s not just trying things to see if they work.

This is a short post because rather than simply listing the things that Hinckley did without explaining the reasons for them, I’m going to send you over to his post to get the full story. If you’ve tried using TRAMP but found it too slow for your particular workflow, take a look at Hinckley’s post. His changes are easy to implement so you can try them out without a lot of effort.

Happily, my use of TRAMP mostly involves the local network or remotes connected with a high speed network so I usually don’t experience these slowdowns. Even so, it’s probably worth implementing his changes.

Many of us run Emacs on multiple platforms. Some, like me, simply run several OSs on our various computers, and some have one system type at work and another at home. Regardless, we all want a one true Emacs configuration that adapts itself to whatever system it’s running on. Using a single configuration file means that you can make additions or changes and have them reflected across all your systems. Trying to keep such changes synced across several configuration files will, believe me, end in tears

Over at The Emacs Cat, olddeuteronomy, who deals with three different operating systems, explains how he handles a single Emacs configuration for all his systems. The key to all such systems is using the Emacs variable system-type to discover what OS you’re currently running on and then conditionally executing system specific settings. Since most settings don’t depend on the system type, this makes it easy to adjust general configuration items and have them take effect across all the systems at the same time.

Rather than clutter up my init.el with a bunch of conditionals, I use the following code at the start of my init.el:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Pull in system and platform specific configurations                    ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;; Just keep on going if the requisite file isn't there.
;; Manipulations in second load is for "gnu/linux" → "linux"

(load (car (split-string (system-name) "\\.")) t)
(load (car (reverse (split-string (symbol-name system-type) "/"))) t)

The first statement loads a file with the same name as the computer’s name. The second loads a file with the name of the OS type. That way I can have a file, named darwin.el, with all the macOS specific settings and another for Linux specific settings. Similarly, if I need some machine specific settings—such as screen size—I simply put them in a file with the machine’s name and the settings get applied automatically. I don’t remember where I got the idea for that strategy but I’ve been using it for a long time and it works well for me.

Whatever method you use, if you’re dealing with more than one machine you probably need to adjust your init.el to handle them all seamlessly.

Over at the Emacs subreddit, kudikarasavasa asks a question dear to the hearts of many of us: How did you start living inside Emacs permanently? He says he keeps hearing people say they live inside Emacs and the idea seems appealing to him but he doesn’t understand how people made the journey. Did they start out to live in Emacs or was it just something that happened along the way?

Of course, it’s the answers not the question that are interesting. There are all sorts of stories. The majority of them say that living in Emacs is just something that happens after you’ve been using Emacs for a while. The usual story is something along the lines of starting to use Emacs, liking the interface, and moving all the easy tasks, coding, writing, note taking, agendas and TODO lists, and maybe even version control via Magit, into Emacs. Later, these people find, as I did, that writing and editing in other applications has become painful.

So they move “harder” applications—like email and RSS readers—into Emacs. Pretty soon, they start thinking, “why should I have to go a separate app to play music?” and they move their music playing into Emacs. Before you know it, they’re doing everything except, perhaps, browsing from within Emacs. Like me, they probably have a couple of tasks that they use other apps for—calendar, texting, and reminders for me—and that remain outside the Emacs sphere but essentially everything else is done from the comfort of Emacs.

Some of the other people are a bit more hardcore. I especially liked this quote:

The alternative journey is you read a lot of stories about Lisp, get hyped about Lisp machines, figure out that Emacs is the best you can actually get, and decide to run with it as far as you can.

I can relate.

It’s worth reading all the comments because there are several useful suggestions for dealing with things like shells and remote editing. As this post shows, it’s pretty easy to move the majority of your computer tasks into Emacs. It’s a really interesting discussion and well worth spending a few minutes reading.