Irreal

Eric MacAdie has a contribution to this month’s Emacs Carnival that talks about his major mistake in learning and using Emacs. That “mistake”, he says, was not embracing Emacs completely when he was introduced to it. Instead, he learned only a few commands—he estimates about a dozen—and limped along with those. He might as well have been using Notepad.

Fortunately MacAdie did finally fully embrace Emacs and started to learn as much as he could about what it had to offer. This wouldn’t have been much of a story except that I keep seeing people expressing the attitude that they’re too busy to learn Emacs. “Why doesn’t it just work out of the box?”, they ask.

The thing is, it does work out of the box. To be sure, your Emacs life will doubtless involve customizing it to fit your specific workflow but Emacs is perfectly usable without making a single change. The thing is, you have to be willing, as MacAdie was, to actually make the effort to learn Emacs in order to realize its full power.

Learning Emacs is not trivial but it’s also not that hard. Irreal has published plenty of stories detailing its advanced use by non-technical people, most recently here. If you want to advance beyond, say Notepad, put in the effort to learn Emacs. It will reward you far in excess of your effort.

A couple of years ago, I wrote about Chris Maiorana’a post suggesting that writers adopt a one-line-per-sentence workflow. You can read his post on the matter to see his arguments on why. At the time, I wrote that I used that method for my two books but because it worked better with the [GT]roff typesetter rather than for any writer workflow reasons. Since moving to Org mode for my writing I’ve given it up not least because it doesn’t play well with WordPress where a lot of my writing ends up.

Maiorana is back with another post on the subject that those who embrace the method may find useful. His idea is to use Emacs’ hl-line-mode to highlight the current line. That brings some other benefits to the one-line-per-sentence method that Maiorana describes in his latest post.

I used to use hl-line-mode, although not in conjunction with one-line-per-sentence, but stopped because it interacted poorly with some other mode—probably visual-line-mode where it highlights whole paragraphs. Even when I was using it, I sometimes found it annoying despite it being useful for locating the current line. I’m sure I’m in the minority on that so you should definitely give it a try if you’re not familiar with it. It’s builtin so you can simply toggle it on for the current buffer with Meta+x hl-line-mode to try it out.

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.

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.

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.

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.

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.