Irreal

A few years ago, starting in 2016, I wrote a series of articles (1, 2, 3) about my favorite Emacs packages and tips. Reading them now, almost ten years later, I find they’ve aged well. I still use everything on the list and my “can’t live without” packages are pretty much the same. I didn’t include Org mode or Magit because, even then, they were given must haves.

I was reminded of all this when I saw a post on the Emacs subreddit from macro_. The post asked what are the must have Emacs packages in August 2025? Once you get past the usual ankle biting, the answers are revealing. Although consult and Ivy were mentioned frequently there seemed to me be less emphasis on actual editing and more on things like LLM and LSP. For example, no one mentioned Steve Purcell’s indispensable whole-line-or-region. I use it many, many times everyday—probably more than any other package.

Still there are plenty of good suggestions in the comments and they are well worth taking a look at. Everybody’s opinion will differ, of course, but I find it really useful to see what others think and why they think it. Sometimes they even convince me to try out one of their favorites. Take a look at the comments and see if there’s anything there that might improve your workflow.

James Dyer has another in his series of posts describing the sanding down of his workflow. This time he troubleshoots and resolves a problem with minibuffer file completion. His specific problem was that he didn’t like the way fuzzy file completion was working.

The default behavior was to have whatever he entered match any file name that had the same letters in the same order even if they weren’t consecutive. What he wanted was to match any files whose name had a substring that matched his input.

As usual, Emacs has you covered. There’s a completion-styles parameter that you can set to get the exact behavior he wanted. Except it didn’t work. It turned out that another function in the call path was resetting completion-styles to the behavior he was trying to avoid.

It wasn’t too hard to fix this and you see how he did it in his post. There was another small issue that he also fixed. Again, see Dyer’s post.

The meat of his post for me was his three conclusions at the end:

1. The source code is always easily available and you can solve most problems by looking to see what is actually happening.
2. Be wary of local versus global settings.
3. With Emacs, there’s always another way. If you don’t like the way something works, Emacs probably provides another way of achieving the same end.

Most people probably aren’t going to care about the issue Dyer was fixing—at least I don’t care about it—but the point is that whatever Emacs is doing that’s not quite right for you, it’s almost always pretty easy to fix it.

Álvaro Ramírez and James Dyer have a problem. The same problem. They sometimes need to reindent a region or the entire buffer. That’s easy enough to do. You can select the entire buffer with Ctrl+x h or select the region you want to indent if it’s not the entire buffer and then call indent-region, bound to Ctrl+Meta+\ by default.

The problem is the current mark and point are destroyed. It would be better to have them restored after the reindent operation. Dyer has an easy solution for the case where you want to reindent the whole buffer. It’s just a few lines of Elisp that you can add to your init.el and bind to a convenient key.

Ramírez took a more general approach. He, too, had the problem when indenting the entire buffer but also when reindenting a function or the result of expand-region. His idea was to implement diverted-mode that recognizes mark-defun, mark-whole-buffer, and er/expand-region and restore the point and mark afterwards.

Both solutions are nice. If you mostly just want to reindent the entire buffer, copy Dyer’s code into your init.el and be done with it. If your reindentation needs are more complex, take a look at Ramírez’s solution. It’s easy to specify additional conditions for diverted-mode as your needs grow.

Maybe this never seemed like a problem to you but if it did, these two solutions are good ways of dealing with it.

I’m writing this on September 1 so there’s a new theme for the Emacs Carnival. Nonetheless, one final Elevator Pitch showed up in my feed and it seemed worthy of a few words. The post is from Philip Kaluđerčić and seems to me to be a particularly well thought out explanation of why one might want to adopt the Emacs way of life.

The term “Emacs way of life” may seem a bit overwrought but I think it captures the way many Emacs users feel about their editor. For a lot of us, Emacs informs the way we think about and approach our computing.

Kaluđerčić starts his post with a short list of things that are great about Emacs and the reasons you might want to embrace it. The list is short but heavily footnoted. The meat of his arguments are in the footnotes, which are much longer than the text they reference. Take a look at them and see what you think.

As I’ve said before, I’m been a bit obsessed with the Elevator Pitch meme and I’m sorry to see it end. I’ve really enjoyed seeing others explain why they love using Emacs. On the other hand, I’m sure the majority of Irreal readers will be happy to see me move onto something else.

Álvaro Ramírez had a problem. The SVG header in the buffer of one of his apps was occasionally disappearing. The problem was that he didn’t know where to look for the bug. Then it occurred to him that he could use the after-change-functions hook to catch when the header was deleted. The problem with that plan was that he’d only get the changed text and he needed to see which of his functions was causing the change.

He solved that problem with a brilliant bit of Elisp that prints the first few entries of the stack frame whenever a change is detected. The whole thing is only 7 lines of code plus an additional line to install it in the list of functions to be called by the after-change-functions hook.

Half the function is involved with printing the results. the other half captures the data. The code is easy to read and understand. The only thing you need to know is that the backtrace-frames function returns a list of frames from the current backtrace and that each of those frames has the format (flag function arguments...). Ramírez uses only the function part (hence (car (cdr frame))) in his function.

After increasing the number of frames printed, he began to see his own code in the backtrace and soon located the offending code. This was an excellent hack and one that Ramírez says he’s gong to keep in his toolbox.

It’s a nice example of how you can get access to the backtrace in your own executing code. It’s a good trick and one that can be easily adapted to fit your particular needs. If you write Elisp, you should read and understand Ramírez’s function. It is, as he says, a handy thing to have in your toolbox.

The Emacs Cat has an informative post on his Ibuffer Configuration. Although it’s built in, ibuffer isn’t enabled by default so you have to load it with require, use-package, or whatever you use for such things. It’s a nice replacement for the default list-buffers.

The Emacs Cat uses ibuffer to group his buffers logically. For example, all his C/C++ buffers, all his Python buffers, and so on are grouped together. That makes it easy to locate relevant buffers and keep things organized if you have a lot of buffers open. He also integrates icons (via all-the-icons-ibuffer) to make it easy to distinguish buffers. See his screenshot to get an idea of what it looks like.

I do something similar. I don’t care for icons in my listings so I skipped that step and I use the ibuffer-vc package, which also groups packages but collects them according to their version control (magit, in my case) category.

All-in-all it makes looking for buffers easier and helps you stay organized. The Emacs Cat uses the buffer listing a lot more than I do so he has F5 as a shortcut for it.

He also mentions Charles Choi’s Casual Ibuffer that he uses to provide a transient menu for the ibuffer listing. If your buffer listings are long, this can be a big help in adjusting the listing dynamically for your current needs.

If you use buffer listings, you should definitely take a look at the Emacs Cat’s post. He’s got a lot of good ideas.

JTR over at The Art Of Not Asking Why has an interesting post on how how he writes instruction manuals. The post was in response to a question from someone on Reddit.

As for Org Mode itself, he doesn’t have a lot to say. He sets some metadata to get rid of the table of contents, enable inline images, and turn off section numbering. He also sets org-export-with-broken-links to t so that he can still export his document even if the link has changed. He doesn’t worry about the links until it’s time to publish because—in his environment—they tend to change often.

JTR uses Denote as a sort of front end to Org Mode. He uses some of its features to organize and associate his files and to keep track of when they were written. He also uses Pandoc for export because of its support for Word templates. Again, that’s something required in his environment.

The rest of his post talks about the procedures he uses for writing his documentation. For example, he uses the Microsoft Style Guide—even though he doesn’t like Microsoft—because it ensures consistency in his documents and because most of his users are on a Microsoft platform.

Interestingly, he’s parsimonious with the depth of his sections. He feels that a depth of more than two is an indication of an overly complicated set of instructions and a signal that they should be rewritten.

One thing I learned from his post was the use of target=blank (target=_blank is probably better; see this post for the difference) to force a link to open in another tab. Sadly, Org Mode does not have support for this so you have to add it manually.

If you have to write documentation and you’re an Emacs user, take a look at JTR’s post. It may have some useful ideas for you.