Irreal

A week ago, I wrote about the recent restoration of the Guile Emacs project. Despite my enthusiasm for the original project, I just couldn’t get excited about its resurrection. You can take a look at that post for my reasons why.

To be clear, I believe that if Emacs were being written today, Guile would be the natural choice and a great one. But that ship has long since sailed. Emacs is 40 years old and there are plenty of technical and political reasons arguing against trying to retrofit it now.

Still, it’s an interesting project. If you’d like to know about more about it, LWN has a nice summary of the project and the talk that its leader, Robin Templeton, gave at this year’s EmacsConf. The article lays out the rationale for the project as well as some of the problems—technical and political that it’s apt to encounter.The project is actually pretty far along but there are still performance and other problems to resolve. There’s also the issue of whether the basically conservative user base would accept such a change. As hard as it is to believe, not everyone is as fond as Scheme as some of us and others just hate change, especially in something as essential as their editor.

Jack Baty has a post that considers the best way of building an Emacs configuration. On the one hand, something like Doom Emacs provides a complete, no-brainer configuration that requires little effort on the part of the user. On the other hand, some people want to build their own and while they may accept some help basically want to be in complete control.

A curmudgeon might suggest that those in the former class consider moving to something like VS Code. After all, that’s the strength of editors like VS Code: no thought configuration that works out of the box. But that’s not really fair. Emacs is, for sure, a DYI editor kit but some folks just want to enjoy its superior editing environment without having to build it for themselves. One of the glories of Emacs is that you can have it either way.

For my part, I would never want to use a prepackaged configuration. From the beginning of my career—from my n00biest of n00b days—I have hated black boxes. Every time I found one—usually in the form of a library routine—I had to peek inside to see what was really happening. My Emacs configuration is the same: I want to understand everything that’s going on.

I could, of course, use something like doom and figure what was going on but why? An Emacs configuration is—or should be—highly personal, sculpted to precisely fit your workflow. It’s true that building it piece-by-piece will take longer but in the end you will have something that fits your needs exactly and that you understand completely.

There are lots of different types of Emacs users, of course, but two distinct classes are those, like me, who stay pretty much up-to-date and those who are stilling running old versions of Emacs and are not familiar with what the latest releases have to offer.

It’s easy to dismiss the latter class as a small, insignificant group of users but I’d guess that there are more of them than many of us suspect. Over at Lambda Land, Ashton Wiersdorf has an interesting post on what’s new in Emacs in the last decade.

Even if you stay up to date, it’s interesting to see how Emacs has progressed in the last decade. Wiersdorf’s lists several broad groups of improvement:

• Completions
• Eglot
• Projects
• Tree-sitter
• Dictionary lookup
  • Flyspell
  • Diictionary definition lookup
• Visual Line Mode
• Themes
• Package Manager
• Emacs Ecosystem
  • Magit
  • Vertico
  • Consult
  • Corfu
  • Citar

Wiersdorf also has a starter kit, emacs-bedrock that provides some of these improvements for those who would like to move up. If you’d like to update your Emacs experience, take a look at Wiersdorf’s post.

Every programmer—at least every programmer who actually programs—is familiar with the concept of flow. It’s a well established concept with lots of research to back it up even if some don’t believe in it.

The trouble is, there are lots of people who are completely unfamiliar with the idea and think nothing of interrupting a programmer for the most trivial of reasons. What to do? Some programmers have the convention that they’re not to be interrupted if they have earphones on. Others put up signs or other indications that they’re working and should not be bothered. The problem with these schemes is that the programmer has to remember to invoke them and then disable them when done.

Enter Shae Erisson. He’s developed an automatic signaling system that turns on a “Busy” sign when he’s typing into Emacs. When he stops typing, the sign changes to “Free”. It’s not foolproof, of course, because some psychopaths just won’t care and will interrupt you anyway believing that their needs, however inconsequential, take precedence over your need for focus. Still, it’s a good beginning.

The only special part of this is a magtag from Adafruit. It’s a cheap bit of kit that’s easy to program. You can see the code that Erisson used at his post. There’s code for Emacs—to detect typing—and code for the magtag to display the results.

If you work in an environment where people feel free to interrupt you for the most trivial of reasons, perhaps this will help. Take a look at Erisson’s post to see if his ideas will help you.

Protesilaos Stavrou has a post with a really nice tip. Almost all Emacsers know about save-some-buffers if only from fat fingering its default binding of Ctrl+x s instead of save buffer bound to Ctrl+x Ctrl+s.

As Prot says, that’s handy but often you’re not sure of whether you should save a particular buffer or not. Fortunately, there’ a command to run a diff against the current buffer and its underlying file. Unfortunately, there’s no default way of calling it in the middle of a save-some-buffers command.

Of course, Prot being Prot, he decided to fix that. It turns out to be pretty simple. You just need to add another entry to the save-some-buffers-action-alist. Take a look at Prot’s post for the details. Even if you use this capability only occasionally, it’s worth adding the minimal code to your init.el to have it available when you need it.

Update [2024-12-12 Thu 13:22]: Added link to post.

I remember that a long time ago I was excited about the Guile Emacs project. It’s aim was to replace Elisp with Guile Scheme while maintaining comparability by making Scheme grok Elisp. To be honest, I can no longer recall why the idea excited me. It seems like empty engineering to me now.

Regardless, after a decade the project has been restarted. Robin Templeton gave a talk at Emacs Conf 2024 on the current status of the project and what they hope to accomplish. A lot of what Templeton has to say boils down to:

• Scheme being more efficient
• Scheme being a much more flexible and extendable Lisp

I think my original enthusiasm was probably the result of the promise of increased performance but now that we have native compilation, that doesn’t seem so persuasive.

A lot of Templeton’s argument involves the possibility of reducing the amount of C code. Unlike many others, I don’t see C code as bad in itself, but Templeton makes the point that those parts of Emacs written in C are not extensible in the same sense that those parts written in Elisp are.
To me, reducing the amount of non-extensible code is a worthy goal but I’m inclined to think that native compilation can do that just as well,

The takeaway is that my previous enthusiasm notwithstanding, I don’t really see the need for a Scheme Emacs. Still, it will be interesting to see how the projects plays out. Guile is a great platform and if Emacs were being written today, it would make sense to use it but that ship has sailed.