Irreal

Marcin Borkowski (mbork) has a nice post on the Jinx spell corrector. Mbork has tried fly-spell but found it too laggy for his purposes. That was back in the days when he had a Pentium class machine running at 100 Mhz so he thought, in view of his more modern hardware, that it was worth trying out fly-spell again.

He still found it too slow and decided to try Jinx instead. I’ve always found fly-spell snappy and I hadn’t heard of Jinx until I read Prot’s post on writing (and spell correcting) foreign languages in Emacs but mbork wasn’t satisfied until he tried Jinx. He found that it was fast enough for his use cases and decided to embrace it as his spell corrector.

He discovered that Jinx interfered with some of his work flows but it turned out to be pretty easy to fix those. You can check out mbork’s post for the details.

If you are writing in multiple languages with Emacs, then Jinx may be an excellent solution as a spell checker. If, like me, you mostly write in your native tongue, you’ll probably find fly-spell is all you need. As I said above, it’s more than fast enough for me and provides a wonderfully interactive spell correction system.

Protesilaos Stavrou (prot) has an excellent video that addresses a problem I often see people asking about. The problem is how to globally set a key binding so that it won’t be overridden. He uses setting Meta+o to other-window as an example to explore the problem.

Prot begins by defining Meta+o in the global map in the usual way:

(define-key global-map (kbd "M-o") 'other-window )

That works well until he tries it in an HTML buffer. In the HTML buffer, Meta+o turns out to be a prefix key for inserting an HTML face command. The problem is that Emacs will use the most specific bindings first. Global bindings are the most general, followed by major mode bindings, and ending with minor mode bindings as the most specific.

Since HTML is a major mode, its keybinding take precedence over the global binding that we set. The answer is to get more specific yet by defining our binding in a minor mode so that it will always have precedence.

Prot shows how to define a minor where we can define our binding and activate it globally so that it’s always available. Of course, once we have this mechanism set up, we can add any number of bindings to our minor mode. Prot demonstrates this by adding a binding that Org uses.

Take a look at Prot’s video for all the details. He’s also included a copy of the file he was working with so you can see everything without worrying about copying it down from the video. The video is 12 minutes, 45 seconds so it should be easy to fit in.

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.