Irreal

My pal Watts Martin has a post that explores an artifact from the past: the insert key. Martin, who’s been a Mac head much longer than I have, remembers when Mac keyboards still had an Insert. They no longer do, of course, but my Unicomp Model M clone does as do several other PC keyboards. The key was used to toggle between inserting text and overwriting it. Emacs calls the latter overwrite-mode.

The idea of insert mode is that text in front of the cursor is pushed ahead as new text is added behind it. When insert mode is off—that is, when overwrite-mode is active—the text in front of cursor is overwritten. Overwriting text used to be more common but these days everyone uses insert mode and you rarely see it.

Still, as Martin says, overwriting can sometimes be useful and if you have an Insert key there’s no reason not to use it in Emacs. That’s a one liner and easy do in your init.el. On the Mac, the Insert key is usually mapped to Help but on other systems it probably has a different mapping so you may have to experiment to discover what it is.

Finally, Martin wanted a visual clue as to which mode he was in so he changed the shape of the cursor to reflect the mode. Again, that’s easy to do. He uses overwrite-mode-hook to toggle the cursor shape.

While I agree that overwrite-mode can occasionally be useful I don’t—and have never—used it enough to dedicate an actual key to it. I’m perfectly happy to simply call overwrite-mode to turn it on and off.

Protesilaos Stavrou (Prot) has a very nice video on writing foreign languages with Emacs. The main problem for Latin languages are the diacritical marks. Other languages, such as Greek, Russian, and Chinese, have completely different alphabets. In either case, Emacs has us covered.

Prot writes Greek, English, French, and (possibly) Spanish so being able to handle all these languages easily is important to him. His video shows us how he does it. The video is in two parts:

1. Using the Emacs input method mechanism and
2. Multilingual spellchecking.

In the first part, Prot demonstrates how to switch between the normal input method—that is, the characters your keyboard normally sends—and another input method that maps to characters from another language.

He uses French as an example and shows one way (the postfix method) to add the diacritical marks that French uses. I use the same method for Spanish and like it. It’s easy and natural. The only thing that takes a bit of getting used to is using an accent character in a non-diacritical way. For example, when writing with the spanish-postfix method, e' results in é but if you want to write something like “he’s” you have to input he''s .

The second part of the video considers multilingual spellchecking. For that, Prot uses jinx, which is pretty much like the normal spell checking in Emacs except you can check multiple languages. It will underline spelling errors as usual and you can have it offer suggestions for correcting those errors.

I wish I’d seen Prot’s video before I started studying Spanish. It would have saved me a lot of time figuring things out on my own. If you have a need to use Emacs to write in another language, you should definitely take a look at Prot’s video.

Jonas Bernoulli (tarsius) has a long post announcing new channels and versioning on MELPA. Why a long post? And, really, why should we care? It turns out that the process is much more complicated than you’d think it would be and will, eventually, require nontrivial action on the part of MELPA users.

The first question is, Why is MELPA introducing new channels and why are they changing the versioning? The new (experimental) channels are a vehicle for testing the new versioning. The two new channels are Snapshots—that corresponds to the current Regular releases—and Releases—that corresponds to the current Stable releases. The plan is for these new channels to replace the Regular and Stable channels.

The reasons for changing the versioning are technical and you can read about them in Tarsius’ post but the reason we care is that when the official switchover happens, MELPA users are going to have to take certain actions to ensure their ELPA distributions are consistent with the new versioning. Otherwise, the new versioning could make a new version of a package look older than previous versions. Doubtless, when the time comes the MELPA team will provide a script to automate the changeover.

As I said at the beginning, there’s a lot of complicated details involved so you should definitely read Tarsius’ post. He recommends that you get in front of things by changing to the new channels now. His post explains everything you have to do. The official changeover probably won’t be for another year so you have time to prepare.

Update [2026-07-04 Sat 13:33]: Fixed title typo.

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 anything¹ 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.

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.

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.