Irreal

Just a quickie from Álvaro Ramírez. If you’re a Mu4e user and would like to have an email’s status shown as one or more icons instead of a series of comparatively opaque letters but don’t want to deal with all-the-icons, Ramírez has the answer for you.

It’s pretty simple. You choose the icons you want for each status indication—or simply copy Ramírez’s—and add a series of configuration items to your init.el. Those items are listed in Ramírez’s post so take a look if your interested in adding your own.

Sebastian Schulze has an interesting post on handling email To and From addresses. His procedure when supplying an Email address to, say, a Website such as some-site.com is to specify some-site.com@his-domain.com where his-domain.com is his domain. That allows him to apply appropriate filters and discover the source of spam.

In order for this to work, he needs two things:

1. His email provider must pass all email to him regardless of the user name.
2. He has to set the From address on any replies to some-site.com@his-domain.com.

The first item is generally doable if you have control of your domain, especially if you run your own email server. The second is a lot harder with almost every email client. Fortunately Schulze uses mu4e so it’s relatively easy with a bit of Elisp.

Actually, mu4e can almost handle this out-of-the-box. You can specify your email addresses and mu4e will respond with the appropriate From address. Schulze’s situation is a little more complicated. You could do it with vanilla mu4e but you’d have to constantly housekeep your mu4e configuration. Schulze’s solution takes care of everything automatically.

The Elisp required is minimal so it’s an easy solution providing you have your own domain and are using mu4e. My own—not as good—solution is to add specific “possibly spam” addresses to my mail server and use that for sites that are possible sources of spam. Schulze’s solution is clearly superior and worth emulating if you can.

Mike Zamansky, who is well known to Irreal readers for his excellent, some say definitive, Using Emacs Series just announced that he is planning on retiring at the end of the Spring semester. In a series of three posts Zamansky lays out why he is retiring, what he feels he’s accomplished, and what his future might hold.

Irreal has focused almost exclusively on his Using Emacs Videos but I read all his posts and several of them are interesting even if not Irreal fodder. If you’re interested in CS education and how best to train new engineers, you should definitely be reading his blog. It’s low traffic so it’s easy to keep up with.

From a purely selfish point of view I hope he devotes all his newly found free time to making new Emacs videos but realistically we’ll be lucky and happy to get one every now and then. Whatever future he decides on, Irreal wishes him the best and is happy to recognize his many contributions to Emacs and CS education.

I often read complaints about how hard it is to learn Elisp and that therefore we should rewrite Emacs in Javascript or something equally silly. The fact is, of course, that Elisp, like most Lisps, is actually easy to learn and once you’ve spend a bit of time with it, you’ve got a very powerful tool for solving text manipulation problems or, really, just about any problem at all.

Marcin Borkowski (mbork) has a short post that illustrates this nicely. Mbork’s problem is a simple one. He needs to replace all backslashes with double backslashes. That’s a trivial problem in Emacs but Mbork wants to replace only single backslashes so the obvious solutions like replace-regexp don’t quite do the job. No matter, he simply wrote a bit of Elisp that, he says, took him about 6 minutes including the inevitable debugging.

Folks are fond of pointing out, correctly, that Elisp is not the best Lisp but it’s more than good enough for its domain. Sure, things like name spaces would be nice but look at this way, part of what make Elisp so easy to learn is its simplicity.

Okay, okay: I’m weak and can’t stick to even the promises I make to myself. This is yet another post on Álvaro Ramírez’s dwim-shell-command framework. Yesterday, it was combining JPEGs into a single PDF file; today it’s killing processes from within Emacs.

I really like Ramírez’s solution but not for the reason you might think. It’s nice to be able to kill a process from within Emacs but I have almost no need to that. The reason is that I spend virtually all my time in Emacs so if any process needs to be killed, it’s usually going to be Emacs. The second reason is that when I do need to kill a process, I simply click on the Apple icon and choose Force Quit from the menu. That does require the mouse but it’s quick and easy and, most importantly, works even when Emacs is the application needing killing. Still, Ramírez’s, and your, workflow is likely different from mine so it’s easy to see how this can be a good solution.

Why do I like it, then? It’s that it’s a beautiful piece of code and shows how Elisp is well up to the task of retrieving and acting on system information that we usually think of as requiring low level system programming to get at. It’s all Lisp; no cheating by dropping into C or shelling out to a system utility. It’s very nice and well worth a few minutes of study.

I keep promising myself that I’m not going to publish anymore posts about Álvaro Ramírez’s dwim-shell-command articles but he keeps finding compelling new applications for it. The latest is a problem I often have: combining several JPEG images into a single PDF. For me, this usually comes up when I want to combine several receipt images—a bill and credit card receipt, for example—into a single PDF for tax purposes. That comes up all the time in my workflow and Ramírez’s simple application makes it easy.

Ramírez’s post is a useful one if you aren’t aware of the dwim-shell-command framework because he lists all the applications that he’s made/discovered for the it. If, like me, you like to stay within Emacs but sometimes (or often) need to run some application from the command line, dwim-shell-command is just what you need. That’s especially true if the command has a complicated, hard to remember syntax. You encapsulate all the complexity in a simple Emacs function and invoke it from within Emacs. What could be better?