Irreal

Just a quickie today. This post addresses a niche need that most readers probably aren’t facing. Joar Alexander Pablo von Arndt’s girlfriend recently bought a Framework 12 laptop and stylus and wanted to use it to take handwritten notes that she could later organize in Org mode.

That’s the type of thing that sounds like it should be doable with Emacs and, of course, it is. The solution they settled on was to use Xournal++ to take the handwritten notes and org-xournalpp to interface it to Emacs.

Sadly, it didn’t work quite right on the Framework 12 so they wrote a bit of Elisp to do the interfacing. It turned out to be pretty easy. See Pablo von Arndt’s post for the details.

This is another nice example of how you can use Emacs to solve problems with just a little investigation into what’s available and perhaps a bit of Elisp.

Update [2025-12-17 Wed 11:28]: Added link to Pablo von Arndt’s post.

For those of you who like to run Emacs in the terminal, Adithya Kumar has some useful advice. One of the problems with using the terminal is that some key presses are not passed on to Emacs. In graphical mode, Emacs receives key presses directly from the OS while in terminal mode the key presses are processed by the terminal software first.

Kumar’s remedy for this is simple and ingenious. It has two stages. In the first stage, he specifies alternate bindings for the problem keys. For example, his terminal doesn’t do the right thing for Ctrl+/ so he rebound the undo command to Ctrl+c c u. By itself, that’s not a very good solution because it breaks your muscle memory. The second stage is to train the OS to send Ctrl+c c u instead of Ctrl+/.

You need a keyboard mapper to do this, of course, and Kumer suggests ones for Linux, macOS, and Windows. I suppose that this solution has the potential to interfere with other applications needing one of the problematic bindings but that strikes me as unlikely and Kumars suggestion seems like a good one to me. Take a look at his post for all the details. If you’re a terminal user, it will be worth your time.

For a long time I have been a huge fan of abo-abo (Oleh Krehel). He wrote the Ivy, Avy, and Swiper packages that are probably my most used Emacs add ins. Eleven years ago I wrote, “When I get tired of blogging I’m going to write some Elisp that everyday will make a post that says, ‘Abo-abo has a great post today. Go read it.’”

A while ago, abo-abo suddenly disappeared. His programs are still being maintained but little has been heard from the man himself. The accepted story was that he had had a son and was devoting his time to being a father.

Now Patient_Chance_3795 over at the Emacs reddit asks what did happen to him? Someone pointed at this comment from abo-abo giving an update on his situation. The TL;DR is that his son is almost 4 years old and that he hopes to get back to maintaining his packages—and presumably writing others—soon.

Along with all his other users, I hope that fatherly duties will allow him to return to full engagement with our community. He is certainly one of our most prolific members and he has been missed. In the mean time, I salute him getting his priorities straight and devoting his time to his son and family.

Álvaro Ramírez is back with a new video in his Bending Emacs series. This time it’s about the super useful and flexible completing read function. The basic idea is that you supply a prompt and a list of possible answers. The user can scroll to select an answer or use fuzzy matching to pick the desired option.

There are, of course, various flags to fine tune its behavior. The most useful is probably a flag to insist that the option be from the list rather than anything the user wants to enter. To me, one of the nicest things about completing-read function is that it can—almost magically—automatically adjust to whatever framework you’re using. Ramírez and I both use the Ivy framework, which provides an nicer interface to the function. There are other frameworks as well and the completing-read function automatically adapts to the one in use. Ramírez demonstrates this by turning off Ivy and completing-read falls back to its default behavior. This is especially nice when you’re developing an application because you can just write to the default and Emacs will automatically adjust to whatever framework is active.

Ramírez covers all this and shows several applications of completing read that he uses on his system. He even shows how to use it for command line utilities.

I use completing-read all the time in my own development and can’t recommend it enough. The list of choices can be calculated on the fly so it’s very flexible and doesn’t depend on your knowing what the choices are in advance. If you aren’t already using it, give it a try.

The video is 17 minutes, 4 seconds long so plan accordingly.

Watts Martin has an interesting post on calling macOS shortcuts from Emacs. For those who don’t know, a shortcut is sort of like an Applescript script. You can specify a sequence of actions along with some simple looping, give it a name, and call it with a single click or with Siri. If you’re interested, here’s a short introduction.

Martin wanted to capture the weather and location for Org-journal entries as well as a way to add photos to an entry. He couldn’t find a way of doing it directly from Emacs but there were shortcuts that did what he wanted. The problem was how to call them from Emacs and capture their output. Although there is an Emacs shortcuts package it doesn’t appear to have any way of capturing the output.

What to do? It turns out that there’s a shortcuts command line utility that does do what he wants so he wrote a bit of Elisp to call the command line utility and insert the results into the current buffer.

The code is simple as you can see from his post. He also shows the shortcut for picking a set of photos and returning Org links to them. This is a nice solution. Martin leverages a builtin Apple utility to do something that’s not exposed to Emacs and then uses a bit of Elisp glue to make it accessible at the Emacs level. It’s another example—if you needed one—of the power of Emacs to adapt to you rather than the other way around.

A reoccurring theme on the Emacs forums is that it’s somehow a good thing to have a minimal configuration and by implication that having a small number of packages is also a good thing. Arguments can be made that a large number of packages can increase load times and memory usage but most of the arguments I see take the position that a small number of packages is an intrinsically a good thing.

Sludgefrog over at the Emacs subreddit makes the argument explicitly. It is, he says, better to write your own extensions instead of adding a package. Even sludgefrog admits that sometimes—when implementing a major mode, for example—a package is the right answer but thinks writing your own extensions is preferable.

There’s a point to made in his favor. In the open software realm—if not in the Emacs world—there are lots of libraries full of trivial functions that are easily implemented in a line or two. That can and has caused problems when the author withdraws the software or a library gets contaminated with malware. That, of course, is the theme of this famous xkcd comic. To some extent those problems are unavoidable but why subject yourself to them to get access to a trivial function?

On the other hand, there’s nothing wrong with using a package even if you could write the code yourself. We only have so many cycles, after all, so in the absence of other considerations, why spend them solving a problem that’s already solved?

The comments mostly take the middle ground that I’ve outlined: sure, write short fixes or functions but use packages for more complicated things unless you want to solve the problem yourself for educational purposes.

Of course, as always Emacs lets you have it your way. You can—more or less—use only packages or you can write everything yourself. Or you can, like most of us, mix strategies and do whatever is convenient in a particular case.