Irreal

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.

If you’re an Emacser who writes in LaTeX you’re doubtless familiar with AUCTeX. Most of the time, you can depend on Org mode to do the heaving lifting but when you have a complicated layout you may have to invoke AUCTeX.

Randy Ridenour, a professor at Oklahoma Baptist University, writes in LaTeX using AUCTeX and, of course, wanted to configure it using John Wiegley’s use-package macro. He did what we’d all do:

(use-package tex
    :ensure auctex)

but it didn’t work. It turns you have to do

(use-package tex-site
    :ensure auctex)

instead.

When I saw his post, it rang a bell so I checked my config and I do the exact same thing. I vaguely remember going through the same steps as Ridenour years ago. I no longer recall how I discovered the magic spell but I doubtless found it on the Web somewhere. Ridenour’s problem was getting things to work with Skim. I’ve never used Skim so I had some other problem but the answer was the same.

Once I fixed the problem, I just moved on and so have no idea why you need tex-site instead of tex. I’m sure one of Irreal’s well informed readers will jump in with the answer.

I know this trip down memory lane isn’t all that interesting to most of you but I’m writing about it for the same reason that Ridenour did: to help someone else struggling with the problem find the answer.

Álvaro Ramírez has another video in his Bending Emacs series out. It’s about something that we see all the time but may not even be aware is happening or how it works. The subject of the video is overlays.

Overlays are a way of decorating, changing, or hiding text. A nice feature of them is that the underlying text is not changed. Rather the changes are simply overlayed on top of it and when the overlay is removed, the underlying text in the buffer is revealed again.

Although it may sound complicated or obscure, it’s actually pretty simple: you simply specify the beginning and end of the text you wish to overlay and make a simple call insert the overlay. Ramírez has a bit of code that shows several different type of overlays and invokes them one by one in the video. It’s a nice demonstration because you get to see many of the things overlays can do.

After those demonstrations, Ramírez shows some “experiments” he’s done with overlays. One of them completely change the look of the text by adding images and looking up and adding additional data on the fly. Another takes a regular expression and “redacts” anything it matches by replacing the text with x’s.

The video is 11 minutes, 57 seconds so plan accordingly but it is, believe me, worth a few minutes of your time to explore what’s possible with overlays.