Irreal

As you all know, I really like the idea of email within Emacs and collect various solutions to implementing it. I’ve long settled on mu and mu4e and have no intentions of looking for something else. Still, it’s nice to see what software and configurations other people pick.

Aqeel Akber has settled on his own perfect email setup. His uses notmuch for both the indexer and mail client. Like me, he uses to mbsync to retrieve his email (from Google in his case). Unlike me, he uses msmtp to take care of sending his emails. This is an advantage because, among other things, it takes care of queuing his emails if they can’t be sent immediately.

Akber likes to partition his computer system into “subsystems,” which he believes makes them easier to configure, manage and reason about. His configuration reflects this but you needn’t blindly follow his setup. On the other hand, if you want to, you can simply download his configuration and make the necessary changes to have a similar system. If you’re looking for an Emacs/Email solution, Akber’s post is worth taking a look at. A problem that many seem to have is how to get mbsync to work with Gmail. Akber has solved that problem so if you have it too, that alone makes his post worthwhile.

I have always felt that knowing, at least in a general way, how a higher level language compiles down to machine code enables one to write better code in the higher level language. That’s not to say that everyone should learn their processor’s assembler language—that’s not necessary these days and would require an effort greater than the expected returns—only that you should be able to read an assembly listing and get a general idea of what it’s doing. This seems so obvious to me that I don’t understand how people can disagree. Some do, however, and they probably won’t be interested in this post.

For many languages it’s possible to get a listing of the assembler output or, in the case of languages like Python, a listing of the bytecode. The problem is that in most cases it’s enough trouble that you won’t bother unless you have a pressing need. Jay Kamat’s RMSbolt package makes everything easy and will give you an automatically updating display of the generated code in a window next to your source code.

Take a look at the animated GIFs in the project’s README to see it in action. This is really ideal because it will let you try alternative statements and see how their code differs. Compilers are always doing surprising things, sometimes even erroneous things, so this can be very useful.

RMSbolt supports C/C++, OCaml, Haskell, Python, Java, Pony, and (limited) Common Lisp. It’s available from Melpa and doesn’t require anything other than Emacs 25 or greater and whatever compilers you’re using.

UPDATE [2018-10-03 Wed 17:55]: Fix link.

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.