Irreal

Ross Baker, channeling the late, great Meatloaf, has a contribution to Greg Newman’s Emacs Carnival on writing with Emacs entitled Writing in Emacs: two out of three ain’t bad. The title comes from the three ways that Baker writes:

1. Alone
2. With asynchronous collaboration
3. With synchronous collaboration

Baker uses Emacs and Org mode for the first two. After all, despite what anyone else might tell you, Org mode is the absolute best way of writing text that you want to do “something else” with later. By “something else” I mean, perhaps, publishing it on the Web, turning it into a PDF, or even exporting it to that spawn of the devil from Microsoft. Even if you’re just writing for yourself with no thought of exporting it, there are a lot of advantages to writing in Org mode.

It’s the third category that gives Baker problems. Lots of people—for reasons I’ve never been able to understand—like to pair program and have two or more people modifying the same piece of text simultaneously. To my mind, that’s the way to madness but plenty of serious people, like Perry Metzger, swear by it.

Regardless, if you do want to pair program it’s pretty much impossible in Emacs. Folks who need it are forced to do the unthinkable and use something like Google Docs. That’s what Baker does. He’s hopeful that Ethersync and its nascent Emacs interface will allow him to avoid the horrors of things like Word and Google Docs.

Álvaro Ramírez is a genius at what might be called programming at the edges. By that I mean he’s good a finding and solving small problems that can negatively effect our workflows. A great example of that is his dwim-shell-command package. Of course, he written some full fledged applications such as Journelly as well.

His latest example of programming at the edges is a post on how to patch an Emacs from Homebrew. For those who don’t know, Homebrew is a package repository that provides pre-built packages for macOS and Linux.

After a long time of building Emacs from source, Ramírez starting using Emacs Plus from Homebrew. It’s a lot easier than worrying about library dependencies, especially on macOS. But what happens if you want to patch Emacs Plus or some other Homebrew package?

Ramírez, of course, has the answer. It’s just the sort of problem that he excels in. There’s no point in me repeating his procedure. Most of us won’t need it but if you’re one who does, take a look at Ramírez’s post.

Álvaro Ramírez, whom I’ve a written a lot about lately because of his excellent Journelly app, just announced that an Emacs patch of his has been accepted and merged into Master. That sort of thing happens everyday, of course, but Ramírez’s contribution is unique because it started life as a macOS specific capability. The FSF’s way of punishing apostates who use macOS or other “non-free” software is to refuse to accept patches to Emacs that are specific to such software.

Because of this, Ramírez didn’t have much hope of having his patch accepted but he persevered nonetheless and, thankfully, it was accepted. He rewrote his patch to be a framework that would work on any OS if the necessary support modules were provided.

The patch, as originally conceived, was an Emacs interface to the the macOS share functionality. As accepted, the framework will do the same thing in any system that provides the necessary interface modules.

Like Ramírez, I’m grateful that Eli Zaretskii and Steven Kangas recognized the value of his contribution and worked to make it acceptable to the wider Emacs community. It’s not a groundbreaking change but it will make it a bit easier for us to meet our goal of being able to stay in Emacs as much as possible.

I’m not sure, and Ramírez doesn’t say, when his changes will appear. They’ve been merged into Master but I don’t know if that means they’ll appear in Emacs 30.2 or if we’ll have to wait to Emacs 31. Regardless, it’s a nice change and will make all our lives a bit nicer regardless of which operating system we’re using.

I could have written these words:

If you are anything like me, you probably feel something is wrong whenever you have to input text outside of Emacs.

but I didn’t. They were actually written by Thanos Apollo. Like me, he loves the idea of Emacs Everywhere so that he seldom, if ever, has to input text outside of Emacs. The problem is, he’s a Wayland user and the Emacs Everywhere package doesn’t (yet?) work there. Happily, for those of you running Emacs on Wayland, he has a fix for you.

There’s a bit of Elisp to add to your init.el and a package, wtype, to install if it isn’t already on your system. His post shows you how to set things up step by step so take a look if you’re interested.

If you’re not using Wayland—in particular if you’re on macOS—this doesn’t apply to you and you should just install the Emacs Everywhere package. But if you are using Wayland, welcome to the club. I’m sure that you’ll find, like Apollo and I, that being able to input text with Emacs no matter what app you’re in is a game changer and stress reducer.

Update [2025-07-21 Mon 11:00]: Fixed title typo.

If you follow Charles Choi’s work, you’ll know that, unlike some of us, he’s not afraid of menus and uses then frequently. His latest hack is to take a look at—and reimagine—the Emacs Help menu. You can read his post for all the details but the thing I really like is popping up help in a new frame. The result is that you can keep the help around for as long as you need it without feeling the need to reclaim the screen real estate.

You can do that with buffers in a single frame, of course, but putting it in an separate frame makes it seem more disjoint from your working environment: it’s right there if you need it but it’s not cluttering up your working buffers.

Choi implements this with three new commands:

1. Open an Info buffer in a new frame
2. Open a new Info instance in a new frame
3. Open a Man page in a new frame

This seems particularly nice if you have enough screen real estate to keep the new frames visible. All the information is there to consult without disturbing your working buffers. It’s a nice way of removing a bit of friction from your workflow.

We here at Irreal prefer not to use menus—although we have been known to under duress—but I really like the idea of invoking separate frames for help. Choi gives the code for his changes so it would probably be trivial to bind the functions to a key shortcut instead of—or in addition to—a menu. Take a look at Choi’s post and see what you think.