LaTeX Preview In Emacs
Over at the Emacs subreddit, _DonK4rma shows an example of his mathematical note taking in Emacs. It’s a nice example of how flexible Org mode is even for writing text with heavy mathematical content but probably not too interesting to most Emacs users.
What should be interesting is this comment, which points to Dan Davison’s Xenops, which he describes as a “LaTeX editing environment for mathematical documents in Emacs.” The idea is that with Xenops when you leave a math mode block it is automatically rendered as the final mathematics, which replaces the original input. If you move the cursor onto the output text and type return, the original text is redisplayed.
It’s an excellent system that lets you catch any errors you make in entering mathematics as you’re entering them rather than at LaTeX compile time. So far it only works on .tex files but Davison says he will work on getting it to work with Org too.
He has a six minute video that shows the system in action. It gives a good idea of how it works but Xenops can do a lop more; see the repository’s detailed README at the above link for details.
Switching Between Dired Windows With TAB
Just a quickie today. Marcin Borkowski (mbork) has a very nice little post on using Tab with Dired. By default, Tab isn’t defined in Dired but mbork suggests an excellent use for it and provides the code to implement his suggestion.
If there are two Dired windows open, the default destination for Dired commands is “the other window”. That’s a handy thing that not every Emacs user knows. Mbork’s idea is to use Tab to switch between Dired windows.
It’s a small thing, of course, but it’s a nice example of reducing friction in your Emacs workflow. As Mbork says, it’s yet another example of how easy it is to make small optimizations like this in Emacs.
Update [2026-04-16 Thu 11:06]: Added link to mbork’s post.
Alfred Snippets
Today while I was going through my feed, I saw this this post from macosxguru over at Bicycle For Your Mind. It’s about his system for using snippets on his system. The TL;DR is that he has settled on Typinator and likes it a lot.
I use snippets a lot but use several systems—YASnippet, abbrev mode, and the macOS text expansion facility—but none of them work everywhere I need them to so I have to negotiate three different systems. YASnippet is different from the other two in that its snippets can accept input instead of just making a text substation like the others.
In his post, macosxguru mentions that his previous system for text substitutions was based on the Alfred snippet functions. I’ve been using Alfred for a long time and love it. A one time purchase of the power pack makes your Mac much more powerful. Still, even though I was vaguely aware of it, I’d never used Alfred’s snippet function.
After seeing it mentioned on macosxguru’s post I decided to try it out. It’s easy to specify text substitutions. I couldn’t immediately figure out how to trigger the substitutions manually so I just set them to trigger automatically. I usually don’t like that but so far it’s working out well.
Up til now, I haven’t found anywhere that the substitutions don’t work. That can’t be said of any of the other systems I was using. It’s particularly hard to find one that works with both Emacs and other macOS applications.
If you’re using Emacs on macOS, you should definitely look into Alfred. It plays very nicely with Emacs and my newfound snippets ability makes the combination even better.
Some Config Hacks
Bozhidar Batsov has an excellent post that collects several configuration hacks from a variety of people and distributions. It’s a long list and rather than list them all, I’m going to mention just a few that appeal to me. Some of them I’m already using. Other’s I didn’t know about but will probably adopt.
- Save the clipboard before killing: I’ve been using this for years. What it does is to make sure that the contents of the system clipboard aren’t lost if you do a kill in Emacs. This is much more useful than it sounds, especially if, like me, your do a lot of cutting and pasting from other applications.
- Save the kill ring across sessions: I’m not sure I’ll adopt this but it’s easy to see how it could be useful.
- Auto-Chmod spripts: Every time I see this one I resolve to add it to my config but always forget. What it does is automatically make scripts (files beginning with
#!) executable when they’re saved. - Proportional window resizing: When a window is split, this causes all the windows in the frame to resize proportionally.
- Faster mark popping. It’s sort of like repeat mode for popping the mark ring. After the first Ctrl+u Ctrl+Space you can continue popping the ring with a simple Ctrl+Space
- Auto-select Help window: This is my favorite.When I invoke help, I almost always want to interact with the Help buffer if only to quit and delete it with a
q. Unfortunately, the Help buffer doesn’t get focus so I have to do a change window to it. This simple configuration gives the Help buffer focus when you open it.
Everybody’s needs and preferences are different, of course, so be sure to take a look at Bastov’s post to see which ones might be helpful to you.
Days Until
Charles Choi recently saw a Mastodon post showing the days until the next election and started wondering how one would compute that with Emacs. He looked into it and, of course, the answer turned out to be simple. Org mode has a function, org-time-stamp-to-now that does exactly that. It takes a date string and calculates the number of days until that date.
Choi wrote an internal function that takes a date string and outputs a string specifying the number of days until that date. The default is x days until <date string> but you can specify a different output string if you like. That function, cc/--days-until, serves as a base for other functions.
Choi shows two such functions. One that allows you to specify a date from a date picker and computes the number of days until that date. The other—following the original question—computers the number of days until the next midterm and general elections in the U.S. for 2006. It’s a simple matter to change it for other election years. Nobody but the terminally politically obsessed would care about that but it’s a nice example of how easy it is to use cc/--days-until to find the number of days until some event.
Finally, in the comments to Choi’s reddit announcement ggxx-sdf notes that you can also use calc-eval for these sorts of calculations.
As Choi says, it’s a human characteristic to want to know how long something is going to take. If you have some event that you want a countdown clock for, take a look at Choi’s post.
Magit Support
Just about everyone agrees that the two Emacs packages considered “killer apps” by those considering adopting the editor are Org mode and Magit. I’ve seen several people say they use Emacs mainly for one or the other.
Their development models are completely different. Org has a development team with a lead developer in much the same way that Emacs does. Magit is basically a one man show, although there are plenty of contributors offering pull requests and even fixing bugs. That one man is Jonas Bernoulli (tarsius) who develops Magit full time and earns his living from doing so.
Like most nerds, he hates marketing and would rather be writing code than seeking funding. Still, that thing about earning a living from Magit means that he must occasionally worry about raising money. Now is one such time. Some of his funding pledges have expired and the weakening U.S. dollar is also contributing to his dwindling income.
Virtually every Emacs user is also a Magit user and many of us depend on it so now would be a propitious moment to chip in some money to keep the good times rolling. The best thing, of course, is to get your employer to make a more robust contribution than would be feasible for an individual developer but even if every developer chips in a few dollars (or whatever) we can support tarsius and allow him to continue working on Magit and its associated packages.
His support page is here. Please consider contributing a few dollars. Tarsius certainly deserves it and we’ll be getting our money’s worth.
🥩 Red Meat Friday: Rules For Lisp Programs
Over at tfeb.org there’s an amusing post on rules for Lisp programs. The rules boil down to:
- Write only in Lisp
- Don’t use Lisp OOP constructs
- Don’t use the Loop macro
- Avoid package-qualified names
The list is obviously meant to be humor but the thing is, I agree with them all. You don’t really need OOP in Lisp and—sorry true believers—the Loop macro is an abomination that doesn’t belong in Lisp.
Folks over at the Lisp subreddit are not amused. Some are even taking the list at face value, but each item in the list is really a matter of opinion. That’s what makes it so perfect for Red Meat Friday.
Of course, this is Red Meat Friday so we’re all just having fun. Right?
Voyager 1
About 50 years ago some engineers at JPL were building a space vehicle with the Star Trek-like 5 year mission to go to unvisited places and seek out new knowledge. That vehicle was, of course, Voyager 1 and the unvisited places were Jupiter, Saturn, and their moons.
But so much more happened. Instead of a five year mission, Voyager 1 is still operating, has left the solar system, and is sending back data from 15 billion miles away. No other man made object has traveled so far from Earth.
Tech Fixated has a nice story about Voyager 1 and its mission. The first thing to remember is that it was built with 1970s technology. It has an extraordinarily small working memory of 69 KB and uses an 8 track tape recorder as it’s backup store.
That “8 track recorder” was not what you’re probably thinking. It was a specially built machine with 1,076 feet of tape specially designed to withstand the rigors of space. It was so well built that it didn’t have a single failure during its lifetime. In 2007 it was shutdown to save power because of the dwindling power coming from Voyager’s radioisotope thermal generators.
Its radio transmitter uses about the same power as a refrigerator light bulb but is still managing to send data from 15 billion miles away. The one-way trip takes 23 hours. That came into play when the thrusters that keep Voyager’s antenna pointing at Earth went off line. The engineers figured out a possible fix. If they were wrong, Voyager would be destroyed but they sent the command anyway. Once sent, it would take almost 2 days to learn if it worked. It did work and Voyager continues sending priceless data that is available nowhere else.
Tech Fixated’s article has a lot more details. If you’re a nerd, you really should read it. It describes an amazing piece of engineering
Tolerance For Repetition
Floofcode over that the Emacs subreddit asks a question that resonates with me. He notes that he often has a repetitive task and wonders whether it would be worthwhile writing some Elisp to automate it. Usually, he has to repeat the task several times before he gets fed up and fixes it for good. He wonders how other people deal with this. Do they have to repeat the task a certain number of times before automating it or is the criterion more subjective.
I can relate. This happens to me all the time. I keep doing the same task over and over until one day I realize that I’m being stupid and spend a few minutes dashing off a bit of Elisp that solves the problem once and for all. Every time, I tell myself, “Well, I won’t that mistake again. Next time I’m going to get this type of task automated right away.” Of course, the next time the same thing happens.
As to floofcode’s question, I would guess that it depends on the person. For me, it’s a subjective matter. The amount of time I’ll spend repeating the same boring task over and over varies but it always ends in a fit of anger when I ask myself why I’m still doing things manually. The thing is, when I’m repeatedly doing the task manually, I’m not wondering whether I should automate it. That happens at the end when I realize I’ve been stupid.
I guess the answer is something of the sort that after you’ve repeated the task twice, just automate it. Sure sometimes you’ll lose and waste time but in my experience it will most often be a win. I wish I could learn this.
Karthik On Repeat Mode
The other day, I wrote about repeat mode. My take was that it was a way repeating certain commands without having to retype their, possibly, complex prefixes. All of that is true but as Karthik informed me in a comment, there is much, much more to repeat mode than simply repeating commands.
It is a way, he says, of grouping a set of related commands together into a sort of mode. Thus, there is more to Ctrl+x } than simply repeating the enlarge window command. Once you type Ctrl+x you can type any of {, }, ^, v to resize the window in any direction. The Ctrl+x enables a keymap with those four single keys to resize the current window, defining, in effect, a “resize window mode”.
Four years ago, Karthik wrote a long post that explains all this and, at least on an intuitive level, how it works. My first thought was to add an update to my post that pointed to Karthik’s and I did that but then I thought that his post was so good that I should devote a new post to it so that anyone who missed it the first time would see it.
Repeat mode really is an excellent facility—Karthik says it’s a cornerstone of his Emacs usage—and every Emacser should be familiar with it. If nothing else, it’s worth enabling repeat mode so that you can use the built in repeat maps. You can see what they are by running the command describe-repeat-maps.