Saving Emacs Buffers Automatically
A couple of months ago, I wrote about friction in saving files. Emacs, of course, tries to protect you from unsaved buffers by periodically backing them up to a special file. Recovering data from that file can be a bit finicky and since Emacs and modern computers don’t crash very often, you don’t get a lot of practice.
A long time ago, Bozhidar Batsov solved that problem with super-save that saved buffers whenever the buffer loses focus or perhaps every few seconds. It’s all configurable, of course. In the mean time, James Cherti wrote buffer-guardian.el that does pretty much the same thing.
Cherti’s solution took advantage of more recent Emacs features to provide a more reliable solution. When Batsov “stumbled upon buffer-guardian.el” he decided to revisit super-saver, which he hadn’t touched since 2023. He’s improved the detection of buffer focus change no matter how it’s invoked. There are a several other improvements that you can read about in Batsov’s post.
I’m inclined not to like my software doing things automatically that I’m used to asking for explicitly so neither buffer-guardian nor super-saver appeal to me but I’m probably in the minority on this so many of you probably will like using one of these packages. As I say, I don’t use either one so I can’t comment on their relative merits but they both seem like useful and worthy packages.
If you’re bad about saving your files and worry that you may lose work, you should take a look at these packages. One or both of them may be just what you need.
🥩 Red Meat Friday: User Hostile Websites
A month ago I wrote about why I was still using an ad blocker. The TL;DR was that unfiltered websites have become too horrible to be usable. Ads popup to cover the content you’re trying to read, videos play—and loudly—without being invited, and the site doesn’t stabilize for quite a while. Sometimes this activity continues for as long as you’re on the site. Take a look at this site without an ad blocker to see what I mean.
I’m not the only one who has noticed this. Over a Daring Fireball, John Gruber has a post that discusses this problem by reporting on Shubham Bose’s post on The 49MB Web Page. Bose’s post gets its name from this experience:
I went to the New York Times to glimpse at four headlines and was greeted with 422 network requests and 49 megabytes of data. It took two minutes before the page settled.
Gruber and Bose explore this phenomenon and explain why it happens. It’s obvious that the dreadful user experience that these sites deliver aren’t for the readers’ benefit but, they argue, they’re also not for news sites’ benefit. The only ones who benefit are the diseased surveillance-based advertising industry.
The readers lose because it takes time and cognitive overload to read a simple story. The news sites lose because abusing readers is not sustainable and those readers will abandon the news sites when they’ve had enough. But the news sites have decided on the short term advantage of a few ad impressions rather than the long term advantage of sustaining and growing their readership. As I said, only the execrable surveillance-based advertisers win.
It’s way past time that we, the readers, started refusing to play this game and simply ignore the sites that abuse us. My guess is that it would have already happened were it not for the fact that every sane person is using an ad blocker.
Surround.el
That didn’t take long. After yesterday’s post on adapting Bozhidar Batsov’s delete-surrounding-pair function to handle Org markup, Batsov is back with a post on surround.el, a port of surround.vim from Michael Kleehammer. The point of delete-surrounding-pair was to (sort of) emulate Vim’s surround plugin. Now with support.el, there’s no longer a need for delete-surrounding-pair.
Surround does everything delete-surrounding-pair did and a lot more. You can delete surrounding pairs, add pairs, change pairs, mark or kill the content between the pairs, or even kill the text and the surrounding pair. It really is a splendid package and I’ve already added it to my configuration and deleted my adaption of delete-surrounding-pair.
Surround will check if the pair you’re operating on has different opening and closing characters and do the right thing automatically. The other nice thing is that there aren’t a lot of key sequences to remember. Once you pick a prefix that you’ll remember the (single) action keys are mnemonic and easy to remember. In any event, which-key pops up a reminder.
I installed it with the recommended prefix of Meta+’ but keep wanting to invoke it with Hyper+’ so I’ll probably change it but, regardless, I’m already enjoying using it.
Take a look at Batsov’s post or the Github repository for all the details. Batsov’s post has some recommendations on when you should use it and Kleehammer’s repository has information on shortcuts and auto mode, which you should read. This is a really useful package and I recommend that everyone take a look at it.
Delete Org Markup Pairs
The other day I wrote about Bozhidar Batsov’s post on deleting paired delimiters in Emacs and mentioned that he included a bit of Elisp that—sort of—duplicated the behavior of Vim’s surround.vim. The idea is that if you are in a delimited expression and invoke the function, it will ask what delimiter you want to delete and will delete the closest enclosing pair. That obviously has some shortcomings such as not recognizing if one of the delimiters is in, say, a string. Still it’s handy code that does the right thing in most cases.
The code was interesting but I thought I didn’t need it because delete-pair already handled all the cases I was concerned with. As I was writing about Batsov’s post, I had something like =some text= and realized that I didn’t want it displayed in monospace after all. Since delete-pair was on my mind, I tried it but of course it didn’t work because = isn’t a delimiter that delete-pair recognizes so I deleted them by hand.
Later, I realized that I could simply add the Org markup pairs I was interested in to Batsov’s code so I did that and added it to my init.el. It worked perfectly and now I have an easy way of deleting Org markup .
It’s worth noting that Org mode gives you a way to do the opposite too: if you highlight some text and call org-empasize (Ctrl+c Ctrl+x Ctrl+f) it will add the Org markup you choose to the highlighted text.
Note
After I wrote this post, I found out about surround.el. More about that tomorrow.
Non Programmer Use Of Emacs
A recurrent theme here at Irreal is that Emacs is for everyone, not just programmers. Every time I find an example of this I try to write about it. It’s a point that Protesilaos Stavrou made in his recent FOSS @ Oxford talk.
Now, in a lovely piece of serendipity, we have Randy Ridenour providing a real world example. Ridenour is a Philosophy professor and, as he himself says, is by no means a programmer. Still, as Prot suggested, he has learned enough to automate some of his Emacs tasks. He started by copying other people’s code but tried to understand what it did.
Now he needs to convert quiz questions from one format to another for the learning management system that his university uses—see his post for the details. This amounts to running a series of regular expression replacements, which he did by hand for a while. Then he realized—as I always find myself doing—that he could just write a bit of Elisp to automate the process.
Ridenour isn’t a programmer and he isn’t a young turk who grew up with all this technology. He’s old enough to have a married daughter so while he may or may not qualify for the Irreal Geezer Club, he is obviously well along in his career. And yet he finds it easy to learn enough Elisp to reduce the friction in his workflow. His colleagues are probably still grumbling about how hard it is to deal with the quizzes but he’s turned all those problems over to Emacs.
Why You Should Use use-short-answers
A perennial problem for Emacs users are the yes/no prompts that require answering “yes” or “no” instead of just “y” or “n”. The usual solution—adopted by almost everyone—is to alias yes-or-no-p to y-or-n-p. Sometime around Emacs 28 or 29 the new variable use-short-answers was introduced as another way of solving the problem.
The last time I wrote about solving the yes-or-no-p problem, I said,
I’ve had my original aliasing code for at least 17 years and see no reason to change it. When use-short-answers was first introduced, I thought I should adopt it but I never did and as far as I can see, it doesn’t make any difference.
That statement was wrong in two ways. First, as related by Bozhidar Batsov, the alias trick doesn’t always work with native compilation because the call to yes-or-no-p may have been compiled before the alias is made. For that reason, use-short-answers is the better solution because it always work.
The second way it was wrong is that when I went to add use-short-answers to my init.el, I discovered that I had already done so, probably back in Emacs 29.
Removing Paired Delimiters In Emacs
Bozhidar Batsov has a nice post on delete-pair. It’s almost a case of the Baader-Meinhoff Phenomenon. Five months ago—before I wrote about it—I’d never heard of delete-pair and now it’s popping up on Batsov’s blog. Batsov, himself, doesn’t remember hearing about it before either.
For those who came in late, delete-pair does just what it says on the tin: delete the delimiter at point and its matching closing sibling. It’s actually quite flexible and usable in surprising ways as you can see from the_cecep’s original post that inspired mine.
The delete-pair command came to Batsov’s attention because it interacted poorly with his Neocaml package. That turned out to be because delete-pair makes assumptions that might not hold for languages with unusual syntax.
Batsov’s post is mostly a summary of what he found from researching the deletions of pairs in Emacs. For Lisp languages, all you need is paredit which has multiple ways of removing a delimiter pair. Probably the easiest is paredit-splice-sexp.
There’s also smartparens that also has several ways of removing a delimiter pair and has the advantage of working in all languages, not just Lisps. Batsov finds it too heavyweight for his needs but lots of folks swear by it.
Finally, there’s the builtin electric-pair-mode, which keeps delimiters balanced, pairs nicely with delete-pair, and is probably all most people need.
Take a look at Batsov’s post for more details and for a bit of Elisp that recreates Vim’s vim-surround. I was glad to see his post because I was right on the verge of forgetting delete-pair even though I’ve assigned it a keyboard shortcut.
Prot’s Video From His FOSS @ Oxford Talk
Just a quick post today to note that Protesilaos Stavrou (Prot) has published the video from his FOSS @ Oxford talk that I wrote about yesterday. Actually, he says that it’s a modified version of that talk so I don’t know if a video of the actual talk will appear or not.
In any event, the video tracked very well with the transcript that I wrote about in yesterday’s post. The video is a little easier to follow because you can see the changes to the text that he makes during his talk. If you’re the type of person that gets more out of a video than reading a transcript, be sure to take a look. The video is fairly long at 42 minutes, 40 seconds long so you’ll have to put some time aside for it but it’s definitely worth your while.
Prot On Emacs At FLOSS @ Oxford
Protesilaos Stavrou (Prot) recently gave a talk to the FOSS @ Oxford event on the power of Emacs and why he uses it. The video for the talk is not yet available but he does have the transcript that he used for delivering the presentation.
It was a nice talk that explained why Prot believes Emacs is a tool that everyone using a computer should be familiar with and make use of. The TL;DR is that Emacs is extensible and can integrate all the (text-based) tasks you need to perform on your computer. If, as a trivial example, you develop a color and font style that is pleasing to you, you need only implement it once: Emacs will use it for whatever tasks you like. Non trivially, you can arrange for various tasks to communicate with each other and share information if they need to.
Prot stresses a point that Irreal has often made: You don’t have to be a programmer to make good use of Emacs. Writers, teachers, liberal arts academics, and many others can and do leverage Emacs to make their work easier. Of course, if you know a bit of Elisp it’s even better because you can extend Emacs to do whatever you need. Prot himself is not a programmer but he taught himself Elisp and is now a significant contributor to Emacs.
The takeaway from Prot’s talk is that Emacs is all about freedom. Freedom to make whatever changes you like, freedom to explore the source code and see how Emacs does things, and freedom to share with others and learn from them.
Take a look at the transcript or wait for the video if you prefer visual presentations. In either case, it’s well worth your time.
Code Formatting With Emacs
Code formatters. Many people swear by them and always run their code through a formatter before checking it in. I’ve never seen the need for them. I have strong feelings about code format and I always write my code to that format: no need for a separate formatter. At the same time, I recognize that others have strong feelings about their preferred format so I never want to reformat someone else’s code.
There are, in every organization, control freaks who think it critically important that everyone’s code look the same. I’ve never accepted that premise and have ignored formatting guidelines. Somehow, I’ve always managed to get away with that minor recalcitrance.
Still, some people appear to like code formatters and for those people, Bozhidar Batsov has an interesting post on code formatters and how to use them in Emacs. It turns out that there’s a plethora of formatters with slightly different behavior to choose from
Happily the Lisp languages—which I use almost exclusively these days—don’t really need one since for a Lisp, code formatting is really just a matter of indentation, which Emacs handles on its own. Other languages need more work.
One of the problems with code formatters run from within Emacs is that they can freeze Emacs while they run. This is the case of formatters that run before the file is saved. There are formatters that run after the save by asynchronously reading the saved file, reformatting it, and writing it back to disk. This has the small defect that an unformatted file exists on disk for a short while.
Batsov’s post covers reformatters implementing both methods. Some of them allow extensive configuration of the reformatting rules. Others enforce a fixed format. Take a look at Batsov’s post for a really good rundown of all the possibilities.