Irreal

The joke about Emacs being an operating system is an old one but lately the idea seems to be being taken more seriously. Here’s the latest example. Significantly, the poster, Bi-Jean, is a self-confessed n00b who doesn’t work in the tech industry, just someone who likes playing with computers and is curious about the best ways of using them. The idea seems natural to Bi-Jean.

If you believe, as I do, that the best way of thinking of Emacs is as a latter-day Lisp Machine, the idea of it being an OS makes more sense. Specialized applications aside, there’s basically no function that you can’t implement from within Emacs except arguably a decent Web browser. From that perspective, the “real” OS is viewed as a set of device drivers for Emacs. It’s a point of view adopted by many Emacsers who claim not to care what OS it’s running on.

My own view, as someone who does almost everything from within Emacs, is that “My operating system is Emacs and Linux/macOS/Windows is just a set of device drivers” is a nice joke that captures an underlying truth but isn’t truly realistic. I always say that I do virtually everything in Emacs and Safari but the “virtually” provides a little wiggle room. For example, I use Fantastical to sync my calendar across all my devices, the Reminders app to set a reminder across all my devices, and the Apple Messages app for texting—although I do use Emacs to compose the text—so it’s not really Emacs all the way down.
Still, a case can be made that in an essential way, Emacs really is my OS. Perhaps more important is the fact that it doesn’t really matter. I do most of my work—other than browsing—from within Emacs and if that makes Emacs my operating system, fine but I also depend on macOS for more than just running Emacs.

I’ve written several times about Álvaro Ramírez’s DWIM tools [1, 2, 3, 4, 5, 6] and their use in easily invoking command line utilities from the comfort of Emacs. Ramírez has a large collection of such utilities built on the DWIM Tool framework but I’ve never seen anyone else use it for their own work.

Now JTR over at The Art Of Not Asking Why has a post that describes his own use of DWIM Tools. JTR wanted to compress videos while preserving their resolution. That’s pretty easy to do using FFmpeg and JTR knew how to do it but he decided to see if he could use DWIM Tools for the job.

It turned out to be pretty easy as you can read at JTR’s post. The lesson I take from this is not that there’s another application available under the DWIM Tools umbrella but that it’s pretty easy to add one. If you have some command line utility that would be convenient to invoke from within Emacs, you should take a look at DWIM Tools. It’s available from Melpa and GitHub.

My friend and erstwhile colleague Watts Martin has been seeking the one true path of light and virtue. After years of aborted attempts to embrace Emacs, he has, it seems, finally succeeded. Actually, snark aside, I understand his journey. It largely parallels mine.

Back when we were colleagues, I was still a Vim user but had already begun making feeble attempts to move to Emacs. It was always a silly thing, like the default scrolling behavior, that drove me away. In my case, it was finally moving to Lisp that pushed me over the edge to embracing Emacs. Martin’s journey was similar. He tried several times to move to Emacs but it just wouldn’t take, until it did.

While we Emacers can rejoice in another convert, Martin’s post is actually a balanced account of the strengths and weaknesses of Emacs. The downsides that Martin mentions are mostly the usual difficulties that n00bies encounter. Those of us who have made the journey from n00bie to journeyman can forget how hard it was at first. In particular, Martin calls out the difficulty of coercing Emacs into behaving as a “modern” editor by which he means using things like Tree-sitter and LSP. He complains, correctly, that there isn’t a good guide to help beginners configure Emacs to support a useful, modern workflow.

On the other hand, he notes that Emacs can molded into whatever you want it to be. It is, as I always say, a light weight Lisp Machine, although Martin doesn’t use that term. That fact, he says, makes it unlikely that folks who aren’t willing to “hack around with their editors” will ever adopt Emacs.

Martin ends by saying,

But the thing is, I think I also get Emacs. And once you get Emacs, there’s probably no going back.

I doubt he understands how true that is. He’s like a guy who’s fallen into quicksand and doesn’t realize it. For him, as for us, there is no escape.

In response to my post macOS Keybindings In Emacs, Paul R. Jorgensen notes that not every macOS Emacs port has the OS bindings defined. In particular, those ports based on the Mac’s Cocoa interface don’t support them.

Jorgensen has his own post on the matter that goes into a bit more detail. As far as I can tell, unless your using Mitsuharu Yamamoto’s Emacs port for the mac this isn’t a problem but if you’re not using a NextStep based port, you’re probably going to have a problem using macOS keybindings in Emacs.

Not to worry though. If you want those keybindings and your port doesn’t provide them, Jorgensen shows you how to get them. His setup assumes the ⌘ Cmd key is mapped to Super so that, for instance, ⌘ Cmd+s is mapped to Super+s. If you have ⌘ Cmd mapped to something else, it may not work as well. For example, if you map ⌘ Cmd to Meta the way many people do, then ⌘ Cmd+v is going to get you a scroll up rather than a paste.

As I said in my original post, I don’t think that there’s a lot a value in having these bindings added to Emacs—but see hmelman’s comment for an contrary viewpoint—so I wouldn’t bother changing my mappings if you’re a ⌘ Cmd == Meta user. Regardless, as Jorgensen says, “Emacs is a wonderfully flexible tool, is it not?”

I periodically publish reminders that

1. macOS uses some common Emacs editing keystrokes by default, and that
2. You can do much better by adding other Emacs keystrokes to those that macOS will recognize.

Here’s one such recent reminder. Now Bozhidar Batsov has turned the tables and revealed that Emacs also recognizes many macOS commands¹. If you look in ns-win.el you’ll see a rather long list of macOS bindings that Emacs will recognize. You can, for example, save a file with ⌘ Cmd+s or start an incremental search with ⌘ Cmd+f. There’s a surprisingly large number of other such bindings. Take a look at Batsov’s post or ns-win.el for the details.

I didn’t know about any of this except for using ⌘ Cmd+f for isearch. I stumbled on that because I rebound Ctrl+s to swiper-isearch but sometimes wanted to do a regular incremental search. Even then, it didn’t click that Emacs was emulating macOS keybindings.

Other than that—and examples like it that other users may need—I can’t see the point of using those bindings. It seems like just another way of confusing my muscle memory. Of course, as I’ve confessed before, I’m very bad at handling multiple sets of keybindings.

For me, it makes more sense to make Emacs keybinding available to macOS rather than the other way around. Of course, you may disagree and want to standardize on macOS bindings. The great thing is that, as usual, Emacs² let’s us have it our way.

Charles Choi has another great addition to his Casual Suite. This time he helps us with the common problem of figuring out what time it is in some other place. As Choi says, the Internet makes it common to communicate regularly with people from all over the world. Even the introverts at Irreal find themselves dealing with this.

Choi says that the most common way of dealing with the problem is with a clock app—which typically show times from all over the world—or just looking it up on the Internet. I do the latter. When I want to communicate with someone in, say, London, I simply search for something along the lines of “what time is it in London?”.

Choi notes that Emacs already has all the machinery to deal with this sort of thing. It just needs to be pulled together into a user accessible package. That’s what Casual Timezone does. It provides a myriad of ways to map the time at one place to the time at another.

At this point, the Casual Suite has so many useful apps that it’s probably best to simply install the whole suite even if there are some that you don’t use. Choi’s use of transient menus makes it easy to use them without having to deal with a bunch of bindings that you seldom use and probably won’t remember. Take a look at his post for an animation of Casual Timezone in action and see it it’s something that might fit your needs.

Bozhidar Batsov is back with a quick tip that many of you will probably find useful. It’s an improvement to keyboard-quit or, as we all know and love it, Ctrl+g.

One of Batsov’s pet peeves is that keyboard-quit doesn’t function as expected when the minibuffer is active. Happily that and a few other infelicities are easily fixed as he shows in his post. The code that Batsov presents in his post is short. It’s more comment than code yet it does fix the problems that were annoying Batsov.

Here, from the code comments, is what his improved code does:

The DWIM behaviour of this command is as follows:

- When the region is active, disable it.
- When a minibuffer is open, but not focused, close the minibuffer.
- When the Completions buffer is selected, close it.
- In every other case use the regular `keyboard-quit'."

You don’t have to edit Emacs source code. You simply include his function in your init.el and remap Ctrl+g to it. It’s easy to try out his code and if you don’t like it, simply drop back to the default behavior by undoing the key sequence remapping.