Irreal

Á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.

As you can probably tell, I’ve become obsessed with Emacs Elevator Pitch posts. I find them particularly instructive because they require the writer to boil down what they like about Emacs to its essence. The latest offering is from Eric Fraga, who I occasionally mention on Irreal.

Fraga begins with the pitch proper. The strength of Emacs, he says, boils down to three of its essential properties:

Discoverbility

Emacs’ builtin help system means that you can always discover what every command, function, and even keystroke does. That help even includes links directly to the source code.

Stability

Ways of working and code you wrote years ago is likely to still work today.

Malleability

This, according to Fraga, is the most important aspect of Emacs. Rather than having to adapt to Emacs’ way of doing things, you adapt Emacs to do things your way. This can be as simple as changing a binding for a command or as complex as modifying or replacing one of Emacs’ builtin functions.

Fraga continues his post by illustrating that last point. He uses Gnus to read his Mastodon toots via the RSS feed. The problem is that Gnus doesn’t provide very helpful information about a toot so it’s hard to know if it’s worthwhile reading it or not.

Fraga solved this problem by writing his own function to display the information for each toot and replaced the Gnus function with it. Take a look at his post to see the difference. Fraga accomplished this by making basically trivial changes to the existing function and using it in place of the original one. Fraga provides the code so you can see how easy it really was.

This is a nice post because it lays out the basic pitch and then illustrates its main point with an actual example. Take a look.

Update [2025-08-29 Fri]: Added link to Fraga’s post. Thanks to William R. Greene for the heads up.

Although, as I have said, the Emacs elevator pitch is a difficult challenge, several people have stepped forward to meet it. Eric MacAdie is one of those people and has provided his own contribution. His approach is to offer some talking points for such a pitch without making an actual elevator pitch himself.

His points, it seems to me, are an excellent précis of what we love about Emacs and why we’re still using it after other editors have come and gone. His post is well worth reading but here’s a short summary of his points.

• When you’re starting, use a a cheat sheet. It’s not a sign of weakness.
• Don’t try to learn everything at once. After you learn the basics you can start worrying about living your life in Emacs.
• In Microsoft products, everything seems easy in the beginning but you soon reach a point where everything is hard. Emacs is just the opposite: at first things seem hard but you soon reach a point where you can do anything you want.
• Emacs is older than the IBM CUA standards and has its own way of doing things. Instead of asking why Emacs doesn’t follow the CUA standards, perhaps you should ask we everyone else isn’t following the Emacs standards.
• Most things in Emacs don’t change. The things you learned 30 years ago still work. At the same time, Emacs continues to evolve and add new capabilities.
• Completion. Completion is one of Emacs’ magical powers. You don’t have to memorize the key chords for every command. Rather you can use Meta+x and an approximation of the command name to bring up list of candidates. Seventeen years on, I’m still using this technique to find seldom used commands.

As I said, MacAdie’s post is a good summary of reasons to use Emacs. Take a look and see if you don’t agree.