Irreal

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.

I do a lot of my writing on my couch with my MacBook on my lap. That provides a less than optimal typing environment so I frequently mistype a command and end up magically transported to another place and time. Sometimes it’s just to another place in my current file but often it’s to another file altogether.

Apparently, I not the only one who suffers from this. Chris Maiorana, who writes for a living and uses Emacs to do so, has the same problem. He asks, wouldn’t be nice to be able to have a “back key” that would take you back to where you were before you fat fingered some command and were transported into the nether regions.

Maiorana notes that Emacs pretty much has this out of this box with push-mark that stores your location before many location moving commands. It stores your current location in the “mark ring” from which you can pop the location to return to the place where the mark was pushed.

But, asks Maiorana, what if you want to go forward too? It’s not to hard to imagine situations where you want to go back and forward between locations during your editing. It turns out that you can do that too with the help of the backard-forward package. Maiorana has a few more details in his post so take a look if you’re interested.

If you don’t want to add another package, you can simply use Ctrl+u Ctrl+Space to pop the last saved location and go to it.

I use Ctrl+u Ctrl+Space all the time but do forget to use it when I inadvertently find myself in an unexpected place. Whether you choose to install the backward-forward package or simply rely of popping the mark, it’s good to be aware of how simple it is to recover.