Read Extended Command Predicate

Bozhidar Batsov has a post that mentions how M-x shows a lot of commands many of which make no sense in the current context. This has never bothered me because after inputting a few (fuzzy) letters, the display converges on the command I’m looking for. Others, are not so sanguine and find the long list annoying.

It turns out that there’s an easy fix for this: read-extended-command-predicate. As of Emacs 28, You can set this variable to one of 3 values—or nil​—to control the filtering of commands in the candidate list. These are:

command-completion-default-include-p
Exclude on those commands tagged for a different mode.
command-completion-using-modes-and-keymaps-p
Include only commands tagged for the current buffer and those commands that have a keybinding active in the current buffer.
command-completion-using-modes-p
Show only commands tagged for the current mode.

The first option is the most conservative and general and is what Batsov recommends for everyday use.

Batsov also explains how functions can declare what mode or modes they’re appropriate for. That’s simply a matter of listing them in the interactive declaration. There are a lot more details in Batsov’s post so be sure to take a look. The read-extended-command-predicate mechanism is similar to the execute-extended-command-for-buffer mechanism that I wrote about previously.

As I said, the long list doesn’t bother me but if it annoys you, this may be the answer.

Update [2026-04-07 Tue 12:05]: prefix → predicate

Posted in General | Tagged | Leave a comment

Repeat Mode

As many you know, I was a Vim user for a couple of decades before I found the one true editor. One of the things I miss from Vim is the easy to use repeat command. If you’re in command mode and perform some command, you can repeat that command by simply pressing .. Sadly, Emacs doesn’t have anything similar. There are a couple of repeat commands: one for simple commands and another for “complex” commands but I was never able to internalize them.

Happily, there is repeat mode that allows you to repeat a command by omitting the prefix and pressing the last key. For example, if you want to repeat the command to enlarge a window horizontally (Ctrl+x }) you can simply repeat the } as many times as needed.

As Bozhidar Batsov explains, this doesn’t work with every key sequence but it is easy to add the functionality to multikey sequences. The TL;DR is that you have to provide a special keymap that maps the last key(s) to their action(s). Batsov has a worked example to show you how to do it. It’s not very hard. But, it turns out, it can be even easier. Omar Antolín explains in a comment that there is also a macro, defvar-keymap that abstracts all the boilerplate away and makes it really easy to define and install a new repeat map.

Repeat mode still isn’t as nice as Vim’s repeat but it can reduce the friction of repeating certain commands. Take a look at Batsov’s post for the details.

Update [2026-04-06 Mon 11:05]:

Karthik Chikmagalur has an excellent write-up on repeat mode that shows it’s useful for much more than simply repeating a command. See his comment below.

Posted in General | Tagged | Leave a comment

Congratulations Álvaro

Irreal readers can’t help but know who Álvaro Ramírez is, if for no other reason that I’m always blathering on about his Journelly app that is my most used and useful iOS app. But of course, Ramírez has many other excellent apps, many of which are Emacs packages. In particular, there is his dwim-shell-command that allows you to automate shell commands—particularly those with complex invocations—from the comfort of Emacs. There’s also his take on music players, an uniform AI access app, and a lot more besides.

You can check out his blog posts or take a look at his iOS/macOS/Emacs applications. He’s been an independent developer for some time but now he’s taken on a new role: fatherhood. He’s now the proud dad of a new son. He tells us that his output may slow down a bit because, after all, he has to start working on his son’s init.el.

Posted in General | Tagged | Leave a comment

Back-To-The-Office Backfires

Those of you who have been around for a while know that Irreal strongly supports remote work. It’s obviously good for those employees who want it and Irreal has always claimed it’s good for employers too. Sadly, a combination of following the herd and a tendency toward being control freaks has prevented many companies from embracing remote first policies.

The management of these companies always use the same argument: having employees on-site increases synergy and improves productivity. These claims have always been based on “feelings” and claims of obviousness without any actual research to validate them.

Now The Hill is reporting on some comprehensive research that shows these beliefs to be baseless. Businesses that offer their employees flexibility and have a strong remote first policy actually do better on all the metrics that matter to an enterprise. They’re more productive, have better productivity growth, better retention, and—perhaps most fatally for the control freaks—have improved revenue growth over companies with an on-site mandate.

Indeed, one study found that fully flexible companies grew revenues 1.7 times faster than “mandate driven” companies in the years 2019–2024. That’s a hard statistic for the control freaks to shrug away with synergy arguments.

The best summary of the article is its last paragraph, which is worth quoting in full:

Executives face a choice. They can pursue badge-driven control that fails to raise performance and risks losing their best people, or they can treat flexibility as a strategy, design for trust and clarity, and measure what matters. The organizations that choose the latter are building stronger teams and better businesses. The smart move now is not to roll back flexibility — it is to raise the standard for how you lead.

Realistically, we shouldn’t expect much change. The control freaks will continue to talk about water fountains and insist that workers will slack off if they’re not being monitored—preferably in person—constantly. Perhaps evolutionary forces will solve these problems for us. On the other hand, the control freaks are always with us.

Posted in General | Tagged | Leave a comment

Your Commit Messages Should Tell A story

Chris Mariana has an interesting post about making Git commit messages with Magit. Well crafted commit messages, he says, can tell a story about your project than can valuable in the future. The secret is in the “well crafted” part.

Rather than a bunch of messages like “Small edits” or “tweaked the foobar”, your commit message should describe what you actually did. Maiorana is a writer and his examples reflect a writing project rather than coding but everything he says applies regardless of what type of files you’re committing. Take a look at his post for examples of both good and bad commit messages.

The other nice thing about his post is that he shows how to use Git reporting to do some rough analysis. Magit, of course, has easy ways of doing this. Again, see Maiorana’s post for the details.

Finally, he offers some suggestions for writing better commit messages. These are aimed more at the story writer than the coder but, again, they can help someone writing code too;

I must admit to being guilty of writing terrible commit messages, especially for my blog posts. I’m very apt to use Maiorana’s example of “minor edit” instead of saying what I actually fixed. Sometimes, it just fixing a typo in which case “fixed typo” is fine but usually it’s something more extensive and a meaningful commit message helps me locate the commit I’m looking for.

Posted in General | Tagged , | Leave a comment

Anju

We here at the Irreal bunker belong to the cohort that believes every right thinking person eschews the use of the mouse whenever possible. Still, in our honest moments, we recognize that there are some intelligent, skillful people who do like using the mouse.

One such person is Charles Choi, who likes using the mouse and even menus. Emacs, of course, supports mouse use but it’s always been a step child and Choi has had enough. He has, therefore, written a package, anju, that implements several features to make using the mouse in Emacs a bit nicer.

He’s added features to

  • Pop up a window management menu
  • Pop up a configurable list of buffers
  • Maximize current window or return to previous window configuration

Added commands to the context menu for selected text, Org mode, and Dired mode, and added a bookmarks submenu to the Main menu. He’s also reorganized the Help menu.

As I said above, I don’t care very much about any of this but I’m sure there are plenty of people who do. Choi has done a lot of work to make using the mouse and menus in Emacs a better experience both with this package and some of his previous ones.

Posted in General | Leave a comment

Christian Tietze On Emacs Mistakes

In celebration of this month’s Emacs Carnival, Christian Tietze has a post on his mistaken beliefs about Emacs. His “mistakes” were not about his using Emacs in the wrong way. They concerned his mistaken beliefs about Emacs.

His first mistaken notion was that Emacs is old and clumsy. We see this all the time. It’s certainly true that Emacs is old in the sense of having been around for more than 40 years but it’s not old in the way people who say that mean. Emacs is, in fact, a modern editor that offers technology that others are still trying to get working. The canonical examples are Org mode and Magit but there are others.

As for clumsy, n00bies find it that way the same way beginning bicycle riders find bikes clumsy. Once they learn to use it correctly it seems natural and they don’t have to think about how to use it.

His second incorrect idea involves text. He believed that text was not enough and that you needed fancy formatting of your input text. Actually, of course, Emacs’ almost exclusive use of straight text is one of its superpowers. Irreal and just about every other Emacs commenter has made this point repeatedly and discussed it in depth.

The rest of his misconceptions involved what you can do with Emacs. At first he thought he would use it just for to-dos—presumably with Org—and that he would build his configuration by copying and pasting bits of Elisp that he found elsewhere.

Experienced Emacers learn that Emacs will eventually try to swallow every task you do on your computer and that your init.el is a black hole that will suck up any mental cycles that venture close to its event horizon.

Tietze’s misconceptions are common but fortunately every user who sticks with Emacs comes to recognize them for the mistakes that they are.

Posted in General | Leave a comment

Lisp Machines!

Anyone who’s been around Irreal for a while knows of my fascination with Lisp Machines. Part of my love or Emacs is that it’s (sort of) a reimagining of the Lisp Machines. Sadly, I never had a chance to work on an actual Lisp Machine but my fascination and love for them continues.

The idea of the Lisp machine is that although it had pretty much standard hardware components, it had specialized microcode that optimized it for running Lisp. For me, the real win was the software more than the hardware. That software still exists but is encumbered so it’s not available without a steep payment or a bit of piracy. That means that for those who, like me, love the idea of the Lisp Machine, the closest we’re going to get is Emacs.

Ketrainis over at Asianometry has an excellent video that recounts the history of the Lisp machines from their birth to their demise. They were hundreds—perhaps thousands—of times slower than today’s cheap laptop but they were built by and for hackers and everything was user customizable just as with Emacs. Even the microcode could be reprogrammed. Joe Marshall has a great post that describes his reprogramming the Lisp Machne microcode to break DES.

This customizability was a huge benefit that every Emacs user will identify with. If the software didn’t support what you needed it to do, you could simply change it—even at the microcode level—to get the behavior you needed.

Ketrainis’ video is 45 minutes, 21 seconds longs so you’ll definitely need to schedule some time but if you have any interest in Lisp Machines, it’s worth your while.

Posted in General | Tagged , | Leave a comment

Paredit Keybinding Conflicts

There are, I suppose, a few Lisp programmers using Emacs who resist paredit but most of the rest of us have long since succumbed to its charms. It can be a bit difficult to get used to but once you do, it’s a tool you don’t want to live without.

There is a problem though. Since Paredit’s introduction 20 years ago, Emacs has added new default keybindings some of which conflict with the existing Paredit keybindings. I can remember having to remap some of Paredit’s keybindings to avoid this.

Bozhidar Batsov has a nice post that discusses these conflicts and how to deal with them. My use of Paredit is mostly restricted to a small subset of its commands so I haven’t experienced the full impact of these conflicts. Even for those commands I do use—like slurp and barf—the conflict doesn’t bother me because I never use the arrow keys to move the cursor.

If you use more of the Paredit commands, take a look at Batsov’s post for his suggestions for resolving them. Or, you could switch to Fuco1’s smartparens, which avoids these conflicts while providing the same functionality and extending it to other file types.

One thing for sure, if you use paredit-splice-sexp you’ll want to resolve its conflict because Emacs uses Meta+s as the search map prefix and that is too useful to forego.

In any event if you’re a Paredit or Smartparens user, you should definitely take a look at Batsov’s post.

Posted in General | Tagged | Leave a comment

Restarting Running Elisp Code

One of Lisp’s features that seem like magic to those of us brought up with C-like languages is the ability to change the code of a running process, reload it, and continue running with the new code. The amazing thing is that the process is not restarted. It simply continues running but with the new code.

Emacers do this all the time, often without realizing what they’re doing. They make a change, to their init.el, say, evaluate it, and continue executing their current Emacs instance. Sometimes, this is simply changing a parameter value but you can also change a function definition in the same way.

If you’re new to Emacs you may wonder how this magical spell is invoked even though you’ve done it several times. It’s simply a matter of evaluating the new code and continuing. Except when it isn’t. There are some edge cases that can trip you up. In Lisp it’s devar values. Emacs adds defface and defcustom. The values defined by these commands are not changed by a code update. This is on purpose. The idea is that you don’t want to mess with a user’s, say, custom values when you change the code.

Bozhidar Batsov has a nice post that discusses all this with particular attention on how to deal with devar and the other edge cases. For example, I always thought the the way to change devar variables was to evaluate a setq of the variable with the new value but you can also simple invoke eval-defun (Ctrl+Meta+x) to the devar to update the value. This also works for defcustom and defface.

The other nice thing I didn’t know about is the restart-emacs command that restarts Emacs and—with desktop-save-mode​—reloads everything, including the new defvar etc. values. Take a look at Batsov’s post for more details.

Posted in General | Tagged | Leave a comment