Automatically Signing And Encrypting Email With Mu4e
Nicolas Cavigneaux has an excellent post on signing and optionally encrypting emails sent with mu4e. The idea is to sign each email you send and if you have a GPG key for every recipient, encrypt it was well. As Cavigneaux says, it’s pretty easy to sign and/or encrypt messages with mu4e but you have to remember to do it and most people, including him, don’t always remember.
The solution, of course, is to automate the process so that you don’t have to remember. That turns out to be pretty easy to do. Cavigneaux has the necessary code in his post. The basic flow is to check if you have everyone’s encryption key and, if so, encrypt the message. Regardless of whether or not everyone’s encryption key is available sign the message. There are calls available for both the signing and encryption. The process is kicked off with the send-message-hook every time you send a message.
There was a time when encrypting all your messages was the thing to do but difficulties with key distribution have pretty much put an end to the encrypt all emails movement. Most people don’t have keys and those who do will probably be annoyed to receive mundane emails that are encrypted. For those sensitive emails being sent to people you know have keys, you pretty much automatically remember to encrypt them.
That leaves signing. It mostly doesn’t hurt anything1 so it probably doesn’t matter if you always sign your messages, especially if you have reasons to suspect that their contents might come into dispute. I’ve stopped doing even that because, as I say, no one has any idea what it means.
So my takeaway is that if you’re paranoid about certifying the content of your emails or you regularly deal with people who want to ensure themselves that they’re communication with you, it may make sense to automatically sign your emails. Except in special circumstances, I don’t see any reason to encrypt all your emails.
Magit 4.6 Is Released
Jonas Bernoulli is announcing the release of Magit 4.6. It includes, he says, over 300 commits since the last release 6 months ago. You can check Bernoulli’s post for the details but an overview is that the main changes were in
- Blob handling. Working with blobs should be easier and make more sense with this release.
- Experimental syntax highlighting in diffs.
- Improved hook handling that allows for the calling of Elisp hooks from Git hooks.
- Improved commit message processing. List of changed definitions in a diff are now available for composing a git commit message.
As I’ve said before, Magit and Org Mode are responsible for luring many new users into the Emacs event horizon so these improvements are important. Moreover, they raise again the need for supporting this effort. Bernoulli spends full time on Magit on a few other open source projects and depends on contributors for his livelihood Take a look at his support page to see how you can help out.
Deleting To Trash Redux
Over at Emacs Dwelling there’s a nice post on why you should set Emacs to delete files by moving them to trash. That’s easy to do by setting delete-by-moving-to-trash to t. The post has a story illustrating why you should do that: it’s very easy to accidentally delete a file with Dired and if you do it to a file with changes that haven’t been committed to version control you can lose a few hours work. If you don’t use version control, the story is even worse.
The post seemed to me to be a worthy cautionary tale and I thought it would make a good Irreal post but when I began the writing process by entering a file name for the post, delete-to-trash.org, I discovered that such a file already existed from 2022. Even worse, for my blogging plans, it said everything I was planning to say in this post. Nevertheless, that was 4 years ago and the lesson, it seems, is evergreen so it’s worth making the point again. It costs you nothing and in those rare occasions where errant muscle memory causes you to delete a file, it can save the day. So rather than repeat the story I’ll just suggest that you check out the Emacs Dwelling post or my previous effort.
The CBS Report On The Unix v4 Recovery
Today (Monday) on the Unix Heritage Society mailing list, Thalia Archibald reports on a CBS report on the Unix v4 recovery at the University of Utah. Sadly, the report misses the two most important things about the recovery.
The first, that v4 was the first release written in C, was perhaps too much in the weeds for most non-geeks so CBS can be forgiven for not mentioning it. The second point, though, is the most important thing about the recovery: It was a recovery. Until the discovery of the tape in the University of Utah closet, there was no known copy of the release or source code and it was widely considered lost.
In a sense, v4 was the link between the early Unix versions written in assembly language and the more modern versions written in C. Viewed that way, v4 could be seen in the same way as archaeology’s famous missing link.
One point the CBS report does make is that the descendants of v4 are running everywhere today. Every Mac is running a direct descendant and those running Linux are running an OS derived from the same ancestor. Likewise, every Android phone and iPhone is also running software derived from v4.
In any event, if you’re interested in this sort of thing take a look at the CBS clip. It’s only 2 minutes, 36 seconds long so it won’t take you long.
Chen On Red Squiggles
All of us are familiar with the red squiggles that appear under spelling errors when we’re writing text. They appear in Emacs buffers and probably most other applications as well. One place they certainly appear is in Microsoft Word documents. Word is, in fact, where they were born.
Raymond Chen from Microsoft has an entertaining post that examines the history of those squiggles. In early versions of Word, spell checking was a blocking operation that had to be initiated by the user. Later, the spelling check ran in the background so that the results would be available when the user asked for them but that background operation was also blocking so users tended to turn it off. Tony Krueger who worked on many of the early versions of Word was the first to implement on-the-fly spell checking—what we Emacsers call “flyspell”—in Word. To indicate misspellings, he underlined the misspelled words with the red squiggle that we’re familiar with today.
Chen also relates a story involving Penn & Teller and Weird Al Yankovic who were fans of the squiggles and autographed pictures for Krueger. They were, reportedly, cherished by Krueger.
None of this really matters, of course, but it’s a nice piece of our shared history and the story behind a ubiquitous notation that we’re all familiar with but probably didn’t know the origin of.
Linking A Diary Event To An Org Heading
Ray Zeitler has a useful post that describes how to solve a niche problem involving Emacs diary and Org mode. The problem is you have an event scheduled in your diary and you want access to an Org heading for clocking and note taking.
It turns out that it’s pretty easy to arrange that. Take a look at Zeitler’s post to see the exact recipe.
Toggling Ghostel
Randy Ridenour is living proof that you don’t have to be a young nerd to master Emacs and Elisp. Ridenour, a professor of Philosophy, has shown repeatedly that it’s possible for a nontechnical person to become sufficiently proficient with Emacs and Elisp to bend the editor to his will and make it work as he needs it to.
Irreal has recounted some examples of Ridenour’s past use of Elisp to customize his work environment and now there’s a new one. Lately he decided to try ghostel for his terminal emulator. He was already using ghostty as his macOS terminal emulator so the change made sense.
The change worked out well and Ridenour was pleased with the result except for one thing. With his previous Emacs terminal emulator, eat, he was able to toggle the emulator on and off easily but it didn’t work with ghostel. Rather than look for another package to solve this, he decided to fix it himself.
The desired functionality was
- If no instance of ghostel is running, start one in the current window.
- If there is already a ghostel instance running in another window, switch to it.
- If there is a ghostel instance running in the current window, bury it.
Ridenour implemented that functionality with two functions. The first gets the active buffer of any running instance of ghostel or returns nil if there is none. The second function implements the three steps above in a straightforward way. The code is in his post and easy to understand so take a look if you have a similar need.
🥩 Red Meat Friday: Programming Epigrams #93
Someone reposted a list of Programming Epigrams by Alan Perlis from 1982. Many of them are funny, some are just silly, and others are probably incomprehensible to today’s programmers. They are sufficiently well known that they’re mentioned in Perlis’ Wikipedia entry. One that stood out to me was #93:
When someone says “I want a programming language in which I need only say what I wish done,” give him a lollipop.
I’ve heard that before and it always resonated with me but in view of Last Friday’s Red Meat Friday it seems especially timely. What, after all, is “vibe coding” but a desire to simply tell the computer what you want done and have it magically happen?
One could argue that with Vibe Coding the dream of “do what I say” has been realized and that celebration is in order. I’m more inclined to think that Perlis’ prescription is the better reaction.
Simulating The Unix at With Emacs
Charles Choi has a nice post on simulating the Unix at command with Emacs. Back in the old days, Choi used to use the Unix at command to notify himself of various events. In macOS, the at command is disabled by default because its use can deplete the battery. Old habits die hard though, and Choi wanted a way to get the same behavior.
He started with the Emacs run-at-time function that does roughly the same thing as the at command except it runs an Emacs function instead of a command line function. Choi filled that gap with a macOS shortcut that he calls nota. The idea is that a small Emacs function schedules nota with the desired message at whatever time you want.
If you’d like to use his workflow, his post has a link to his shortcut that you can download. Of course, the shortcut bit works only with macOS but I doubt it would be hard to adapt to any Unix-like system. As far as I can see, the shortcut mechanism is merely a convenience and could probably be replaced with something like the Unix message command.
Regardless, if you’re looking for a handy way to serve a notification at a certain time and, like Choi and me, you have Emacs running all the time, take a look at his post.
Why (Some) Bosses Hate Remote Work
Irreal’s opinion about remote work and those who oppose it is well established. It’s basically that absent special circumstances or obvious misfits like retail sales remote work is a win for everyone concerned, employees and employers alike. Indeed, Irreal has often speculated that the insistence on workers being on-site had more to do with some managers being control freaks than any business need. Study after study has shown that in-office policies serve no business need and that remote works tends to foster the results that businesses care about.
That last part is pretty well established now. The part about control freaks could be dismissed as delusional rantings from the Irreal bunker denizens. But now the New York Times has published an article entitled The Secret Reason Bosses Want Everyone Back in the Office, Every Day of the Week. The reason? The bosses who oppose remote work are narcissists.
That’s not just an opinion. In research that studied bosses for and against remote work, researchers found that the only quality that reliably correlated with opposition to remote work was narcissism. Take a look at the article for details. It’s pretty damning for the control freaks who justify their opposition with meaningless cant about water coolers.
There are, of course, plenty of reasons why remote work may not be appropriate for a particular job and there’s some recent research suggesting that working remote 100% of the time may not be optimum. The takeaway is that wholesale opposition to remote work is a more reliable indicator of problems with the denier than with those being denied. Perhaps it’s time for those questioning the motives of employees who want to work remotely to turn their questioning inward.
Posted in General | Tagged Remote-work |