Irreal

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?

Ben Simon has a post that hits two of my blogging hobby horses at once. The post is about his recent adoption of define-word and powerthesaurus. The first way it resonates with me is that Simon, like me, finally got sick of doing things the hard way and implemented a simple solution within Emacs. Like me, once he made the change, he wondered why it took him so long.

In his case, it was changing focus to Google to lookup the definition of a word or to use an online thesaurus to find synonyms. That’s just silly, of course. Emacs has all sorts of packages that will do that—and do it interactively—for you without leaving Emacs.

The second thing that resonated was the solutions he selected. Simon’s choices were the same as mine. He used abo-abo’s define-word for word definitions and Valeriy Savchenko’s powerthesaurus for finding synonyms. They’re good choices and have served me well. As I’ve related many times—most recently here—I also use the Webster 1913 dictionary (usually instead of a thesaurus) to find just the right word. As of Emacs 28, that’s particularly easy and doesn’t even require a package.

My only “complaint” is the Simon chooses to check spelling with ispell-word (bound to Meta+$) instead of just enabling Fly Spell, which automatically checks spelling. I think it’s better than using ispell-word because it finds errors even if you don’t suspect there is one. When Fly Spell finds one, you can use flyspell-auto-correct-previous-word (bound to Ctrl+;) to correct the error. It’s a nice solution that I’ve used constantly for many years.

I’ve written before about Emacs and how it fits into the Unix Philosophy. Those posts all focused on the Unix ideal of

• A program should do one thing and do it well.

The argument is to consider the one thing that Emacs does well is to handle text and consider how it uses that as a sort of universal interface. But the Unix Philosophy is more than the above. It also includes

• Write programs that work together
• Write programs that consume and output text streams

Ashton Wiersdorf also advances the notion that Emacs adheres to the Unix Philosophy but he takes the second and third legs of the philosophy as his starting point. Just as Unix can be thought of as a “tool forge” so, he says, can Emacs. It’s worth reading his argument so I’ll send you over to his post to see it. I will mention, though, that he makes the same point that many others have: it doesn’t matter too much what operating system he’s using because his main interface to his computer is Emacs and that’s the same no matter what OS lies underneath it.

Wiersdorf’s post is short and probably won’t take more than a minute or two to read so it’s worth taking a look.