Irreal

This is an update on my post concerning the Emacs GUI not working on the macOS Majave update. There’s lots of useful information in the comments to that post so you should read those if you’re a Mac Emacs user thinking about upgrading to Mojave. Things are moving fast now. I wrote this post yesterday and I’ve had to rewrite most of it because things have changed so quickly.

Alan Third, who’s been working on the patches to fix this, reports that he’s pushed the patches to the Emacs-26 branch. Davide Restivo says that these patches are now on master as well, and I’ve verified that they have indeed been merged.

Everyone I’ve heard from who is getting their Emacs from distributions like Brew say that they haven’t had any problems (see the comments to the original post) so that’s another avenue if you need or want to upgrade now.

It appears that it’s probably safe to upgrade now but I’ll probably wait a few more days just to see what happens. There may even be an official release, although I haven’t heard anyone who actually knows what’s going on say so. I’ll probably write another update when I upgrade. I compile directly from source so if that works, everything else should too.

I must admit that I seldom use file local variables. Mostly that’s because I have a standard default configuration for each file type but it’s also because I can never remember the exact format. That’s just silly, of course, because Emacs has a command to add them pretty much automatically.

The same thing is true with directory local variables but with the additional complication that I never think about using them. I have code in my init.el that checks if the current directory is ~/org/blog and if so sets certain variables and toggles things like fill-mode and visual-line-mode. That’s crazy because it’s far easier to just use directory local variables to do the same thing.

But again, I could never remember how to set up these variables. Fortunately, Marcin Borkowski (mbork) has me covered. He’s got an excellent post on how to add file and directory local variables and deal with the gotchas that come up. Really, there’s no excuse for my sturm und dang. It mostly boils down to just calling add-file-local-variable and add-directory-local-varible and filling in the blanks but be sure to read his post for the details.

Over on the Emacs subreddit, freetonik has an interesting tip for Emacs users. The idea is to have several frames each dedicated to a particular function. It made me think of Xah Lee because he likes to work (mostly) with frames rather than windows. Really, though, it’s more like what many of us do with our window managers: we dedicate one window to, say, our editor, another to the browser, a third to things like email, and so on.

It’s a natural way to work but I don’t think I’d like it for Emacs. That may be just because it’s not what I do now and that I’d like it if I tried it but probably not. The thing about Emacs is that it’s really easy—especially with Ivy, Helm, or Ido—to find and switch to any buffer you want. In many of the cases mentioned by freetonik, I have dedicated keys to go directly to a desired buffer. For example, F6 brings up the mu4e main menu for email and Hyper+e brings up a full screen eshell.

Still, if like many of us, you’re essentially using Emacs as a window manager (because all your tasks operate inside it), it might make sense to dedicate frames to certain tasks just as we do with “real” window managers. Is anyone, besides freetonik, doing this? If so, how is it working for you? Leave us the benefit of your wisdom in the comments.

As all the Apple faithful know by now, Apple released the latest version of macOS on Monday. I was literally minutes away from starting the upgrade when I stumbled upon a tweet that indicated a problem with Emacs and Mojave:

Anyone running #emacs on #mojave? It seems the text is not rendered.

— Davide Restivo (@gutt3r) September 26, 2018

I did a bit of research and the problem appears to be real. Perry Metzger, who knows a thing or two about Emacs, posted a report to the Emacs-Devel list with the same complaint. The problem is that Emacs is using a now deprecated method of drawing the screen and with Mojave it no longer works. According to the thread, there’s a not-altogether-satisfactory patch available but more work needs to be done by the people who understand that particular low-level area of Emacs.

If you’re using Emacs on a Mac, you should probably hold off upgrading to Mojave until things get sorted out. Terminal Emacs is unaffected so if you restrict your Emacs use to the terminal, you’ll probably be Okay.

I came across this tip on reddit the other day. It’s probably not something you’ll use every day but it can come in handy when you have a lot of processes in your list-processes output and want to kill a bunch of them. This most often comes up for me when I’m having trouble pushing Git updates and end up with several hung Git processes. Mutiple-cursors is a handy way of getting rid of all of them without worrying about stepping down the list and repeatedly typing d.

It’s not going to revolutionize your workflow but, as I say, it can be a handy time saver occasionally.

I’ve been using Emacs for over a decade and like all of us, I’m still learning things I didn’t know about it. Still, this really surprised me. Sure, maybe I don’t know about some obscure command or key binding but a modifier key?

At first I thought the person asking the question was simply misinterpreting something. Then I read the first couple of lines of the answer and thought, “Aha! It’s simply someone trying to convince us to use Alt instead of Meta.” But no. It turns out there really is an Alt modifier and it has nothing to do with the Alt key we all have on our keyboards and map to the Meta modifier¹. It’s a completely different modifier that I, at least, had never heard of. It’s an artifact from the days when keyboards had both Alt and Meta keys. It’s seldom used these days but if you need it, the easiest way to specify it is with Ctrl+x @ a.

Perhaps I’m the last Emacs user in the inhabited universe to learn this but just in case I’m not, I’m sharing the information.

There’s a certain type of writer—mostly prose writers, I’d guess, but others too—who don’t want to be distracted by extraneous information from their editor. They don’t want to see the name of the file they’re editing, what line they’re on, or, in Emacs terms, what mode they’re in. They don’t want a mode line or anything else. The metaphor they’re seeking is the blank sheet of paper.

I remember coming across this same idea years ago; so many years ago I was still using WordStar for non-programming editing. I didn’t understand it then and I don’t understand it now. Knowledge is power, after all, and I never saw the benefit of unnecessarily doing without it¹.

Needless to say, not everyone agrees. A few years ago, Bastien Guerry showed how to achieve a blank screen in Org mode. Now Pete Corey is doing the same thing in Spacemacs (although his approach will, mutatis mutandis, work with any Emacs configuration) using Olivetti. Corey’s approach isn’t limited to Org mode. He likes the blank screen even when he’s coding so he’s arranged for his mode to be active in text-mode and prog-mode buffers.

Most folks probably wouldn’t want such a setup but if you do, Corey shows how easy it is to obtain it with the help of Olivetti.