Irreal

Á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.

As you all know by now, I’m a fan of the Lisp Machine concept. Like the majority of people, I never had the opportunity to work on an actual Lisp Machine—they were horrendously expensive and they haven’t been produced in years. They were never commercially successful but nevertheless enjoy an almost mythical reputation.

Today, the best most people can do is Emacs. That’s pretty good, actually, but Emacs can’t begin to match the power of the Lisp Machine operating environment. Still, most of us have come to peace with the idea of Emacs as the modern Lisp Machine.

Most of us but not all. For example, Fulton, over at Fulton’s Ramblings, believes that not only were Lisp Machines were the right thing but that their time is coming again. He notes that while Unix ran on relatively modest hardware, Lisp Machines required significant hardware including lots of memory and a frame buffer. All that was expensive back then and by the time the prices came down, Unix was well established and had captured the market and mind share.

Fulton believes that Unix has a myriad of problems and that those problems will lead to a resurgence of the Lisp Machine era. As much as I love the idea Lisp Machines, I don’t think this is going to happen. Sure, Unix has grown increasingly complex but that’s because it’s addressing increasingly complex problems. Lisp Machines didn’t have to worry about (hideously complex) things like Web Browsers, or even the ubiquitous Web.

Were Lisp Machines to reemerge, they would undoubtedly undergo the same complexification that Unix has suffered. Don’t get me wrong, I’d love to see a modern Lisp Machine but, really, it’s a nerd dream that would almost certainly be unable to gain popular acceptance. After all, we can’t even convince most nerds to learn Lisp.

Even if the nerd market were large enough, what would we use them for? Presumably software development would be the main use but writing software for different Unix platforms is already difficult enough. Imagine how hard it would be if we were developing it on a completely different system.

I’m doubtful that I’ll see the second coming of Lisp Machines but I do have Emacs which is a pretty good approximation and an excellent compromise given the market and technical realities.

A few weeks ago I mentioned that Sacha Chua is tremendously organized and gave an example of that organization. That example was about how she automated organizing tasks based on her calendar. Now she provides us with another example.

This time, she provides a shortcut for dealing with the thing at point. Someone asked her for a way of either opening the URL at point or searching for the word or region if the point wasn’t on a URL. Chua, of course, not only ran with that but expanded it to be even more useful. She presents code that deals with whatever the point is on in the following way:

• Unless there is an active region, assume that the thing at point is a URL, word, an email address, or a filename. If it is a region, just add the text for processing as below
• If there are links, open them
• If there are email addresses open an email compose buffer with those addresses populating the “TO:” header
• If it’s a filename, open it
• Otherwise do a Web search on the word or text from the region

Chua also describes some nice customizations. You can specify what function to call for searching. This is more than just picking your browser of choice. See Chua’s post for the details. This can even be fine grained. You might want to use different “browsing functions” depending on what kind of link it is. Again, see the post for details.

There’s not really enough code involved to make it into a package but if you’re interested, it would be easy to just add Chua’s code to your init.el.