Irreal

Yesterday I wrote about James Cherti’s Org-ibullets package. Today I’m writing about another package that he announced at essentially the same time: wizard.el. It’s a package of some carefully written Emacs functions dealing mostly with editing and navigation.

Cherti describes his functions as using the builtin Emacs functions rather than third party packages or writing complex logic de nuevo. It’s surprising how far you can get with just what Emacs provides out of the box.

You can look at Cherti’s post or the source code for a list of the functions but their broad categories are:

• Highlighting functions
• Buffer and State Management
• Smart Text Manipulations
• Search & Replace
• Code Navigation

Cherti has more to say about the functions in those categories so be sure to take a look at his announcement. If one of your goals is to reduce the number of third part dependencies in your configuration, this package may interest you.

The ever-officious minions have staged what they’re calling an intervention. They told me that I’ve milked this illness shtick long enough and that it was time to get back to work. They were unmoved by my protestations that I was not yet 100 percent and merely pointed at my computer. They obviously don’t understand the meaning of “minion”. Anyway, I’m trying to get things back to normal.

James Cherti has announced a simple package that trades Org mode’s heading stars for UTF-8 bullets. If you’re like me, your first thought is, “Doesn’t that already exist?” Sort of. What already exists is the no longer maintained org-bullets. Cherti’s package is called org-ibullets (note the i).

Cherti explains the differences from org-bullets in his announcement. The TL;DR is that he’s optimized org-ibullets by eliminating redundant computations, eliminated spurious syntax warnings that org-bullets could produce, and made some improvements at the source level.

As I said, the package is simple. It can be used right out of the box but you can customize the list of bullets and their face if you desire. This seems like a very nice package if you’d like to make your Org buffers look a little nicer.

I’m still under the weather: mostly I’ve been sleeping non-stop except for meals and bathroom breaks. That means that I’m still not up to producing a post with the usual Irreal wit and charm¹. I did have this post from Curtis McHale about the future of Emacs interaction in my TODO queue so I decided to do a quick write up about it.

McHale’s contention is that we use keyboards because they’re the best way of interfacing with computers. He points to everybody’s favorite keyboard replacement, voice input, but notes that even on Star Trek—that arguably popularized the idea—Captain Picard still tells his crew members where he wants to go and they type in the commands at their control stations.

As I said in my last post on the matter. my written thoughts are always much better organized than my verbal ones so moving to spoken input would be a net loss for me. Still, it will be interesting to see how things play out.

The topic that wouldn’t die. It started with a quick post on Sacha’s solution to a problem posed by David Pape. I thought it was a nice solution but then 0-_-0_ pointed out that abo-abo had already solved this problem with his tiny library. So I wrote about that and prepared to move on.

I was not allowed to. Frequent commenter Phil remarked in my original post that he would use a keyboard macro. He suggested that that would make sense for those of us who who seldom need to enter a sequence of ranges like Pape. In Pape’s case this was something that he needed to do a lot so a solution like Sacha’s or abo-abo’s make sense. I agree with Phil. A keyboard macro is exactly how I would solve this problem given that I seldom have it.

This seems pretty obvious and might not be worth writing about except that Phil’s solution showed me something that I didn’t know: You can set the initial value of the counter with a Ctrl+u n where n is the desired initial value. That’s a lot easier than using Ctrl+x Ctrl+k Ctrl+c to do the job.

As a final note, I think that Phil had a typo in his macro. As far as I can tell it should be

C-u 47 <f3> # <f3> , SPC <f4> <f4> <f4> <f4> <f4> <f4> <f4> <f4>

At least that’s what works for me.

It turns out that I regularly use a macro with a counter so I’m really happy to learn that the counter can be set so easily.

Update [2026-10-10 Sat 12:12]: Fixed link.

In a nice coda to yesterday’s post on Sacha Chua’s solution for entering number ranges, 0-_-0_ points out that a solution already exists. That solution is abo-abo’s tiny library. I vaguely remember seeing tiny when abo-abo released it 13 years ago but I never followed up and used it. Still, anything from abo-abo is worth taking a look at and, in any event, we now have two solutions to the problem.

Abo-abo’s solution brings to mind another Emacs lesson: very often, if you need some functionality, there’s a good chance that it already exists. Of course, that’s not the same as being easily discoverable. An internal function can usually be discovered through the on-line documentation but a third party library like tiny won’t appear in that documentation until it’s loaded.

That’s it for today. I just wanted to tell the rest of the story from yesterday.

The incomparable Sacha Chua has a very nice solution to a problem posed by David Pape: how can we enter a range of numbers as list of distinct numbers in Emacs? Pape’s specific problem was entering the numbers of error reports that a Git commit closes. Rather than entering something like

closes: 47, 48, 49, 50, 51, 70

he’d like to enter something like

closes: 47-51 70

and call an Emacs function to have it expanded into the first example.

Chua has a very nice solution that covers that case as well things like

47-51, 70

or even

5-15/2

to expand into the sequence

5, 7, 9, 11, 13, 15

Most of the heavy lifting is done by the number-sequence function. The rest of the work is parsing the input string into either a single number or a range of numbers that number-sequence can work on.

Chua’s solution strikes me as an example of Emacs at its best. The problem it solves is not earth shattering. It’s simply a bit of friction in a user’s everyday workflow but Emacs easily provides a solution that makes the friction disappear. Take a look at her code. It not only shows an ingenious solution to the problem but also demonstrates the power of Emacs and Elisp to make the application of that genius simple.

Chris Maiorana asks a provocative question: What’s the future of Emacs? He asks that question in the context of assuming that Emacs will continue to exist for any timeline that matters to us. But how, he asks, will we use it?

The answer that will occur to most of us is speech mediated input á la Star Trek TNG. We’ll simply tell Emacs what we want it to do and it will do it. But think about that for a moment. Would you really want to dictate the code for your latest program to the computer? Or would you even want to dictate your documentation, story, or letter to your computer?

Sure, you could say something like, “Computer write a program to do such and such.” but then you’re not using Emacs at all. The same for asking the computer to write something for you. That—more or less—is here today but most of us don’t like the results and, again, we’re not really using Emacs in those situations.

For my part, my written thoughts are always much better organized than my spoken ones so even with capable voice input, I’d much prefer to use the keyboard. Maiorana agrees. He points back to a couple of episodes from Tales From the Darkside¹ in which people use the keyboard to do magic with the computer. For him, Meta+x is the spell that enables the magic and he’s very attached to it. Like me, he doesn’t anticipate abandoning the keyboard.

What do you think? Will we still use the keyboard or will we move on to something better?