The minds had long ago come up with a proper name for it; they called it the Irreal, but they thought of it as Infinite Fun. That was what they really knew it as. The Land of Infinite Fun. –Iain M. Banks, Excession

Someone reposted a list of Programming Epigrams by Alan Perlis from 1982. Many of them are funny, some are just silly, and others are probably incomprehensible to today’s programmers. They are sufficiently well known that they’re mentioned in Perlis’ Wikipedia entry. One that stood out to me was #93:

When someone says “I want a programming language in which I need only say what I wish done,” give him a lollipop.

I’ve heard that before and it always resonated with me but in view of Last Friday’s Red Meat Friday it seems especially timely. What, after all, is “vibe coding” but a desire to simply tell the computer what you want done and have it magically happen?

One could argue that with Vibe Coding the dream of “do what I say” has been realized and that celebration is in order. I’m more inclined to think that Perlis’ prescription is the better reaction.

Charles Choi has a nice post on simulating the Unix at command with Emacs. Back in the old days, Choi used to use the Unix at command to notify himself of various events. In macOS, the at command is disabled by default because its use can deplete the battery. Old habits die hard though, and Choi wanted a way to get the same behavior.

He started with the Emacs run-at-time function that does roughly the same thing as the at command except it runs an Emacs function instead of a command line function. Choi filled that gap with a macOS shortcut that he calls nota. The idea is that a small Emacs function schedules nota with the desired message at whatever time you want.

If you’d like to use his workflow, his post has a link to his shortcut that you can download. Of course, the shortcut bit works only with macOS but I doubt it would be hard to adapt to any Unix-like system. As far as I can see, the shortcut mechanism is merely a convenience and could probably be replaced with something like the Unix message command.

Regardless, if you’re looking for a handy way to serve a notification at a certain time and, like Choi and me, you have Emacs running all the time, take a look at his post.

Posted in General | Tagged Emacs |

Irreal’s opinion about remote work and those who oppose it is well established. It’s basically that absent special circumstances or obvious misfits like retail sales remote work is a win for everyone concerned, employees and employers alike. Indeed, Irreal has often speculated that the insistence on workers being on-site had more to do with some managers being control freaks than any business need. Study after study has shown that in-office policies serve no business need and that remote works tends to foster the results that businesses care about.

That last part is pretty well established now. The part about control freaks could be dismissed as delusional rantings from the Irreal bunker denizens. But now the New York Times has published an article entitled The Secret Reason Bosses Want Everyone Back in the Office, Every Day of the Week. The reason? The bosses who oppose remote work are narcissists.

That’s not just an opinion. In research that studied bosses for and against remote work, researchers found that the only quality that reliably correlated with opposition to remote work was narcissism. Take a look at the article for details. It’s pretty damning for the control freaks who justify their opposition with meaningless cant about water coolers.

There are, of course, plenty of reasons why remote work may not be appropriate for a particular job and there’s some recent research suggesting that working remote 100% of the time may not be optimum. The takeaway is that wholesale opposition to remote work is a more reliable indicator of problems with the denier than with those being denied. Perhaps it’s time for those questioning the motives of employees who want to work remotely to turn their questioning inward.

Posted in General | Tagged Remote-work |

As you all know by now, I’m not a Google fan and generally avoid using their products. The one exception is YouTube for videos. Apparently, YouTube also has a radio channel, which is a sort of music streaming service. I listen to my music offline so I’m not interested in steaming services and even if I were, I’d probably use Apple’s or maybe the Amazon service that I get for free as an Amazon Prime member.

Still, lots of people don’t share my antipathy to Google and at least occasionally like to stream music. One such person is Álvaro Ramírez who sometimes has the urge to listen to YouTube radio channels and, being Ramírez, built an Emacs player, ytr, to do that. As usual, he built ytr to scratch and itch and is using it to experiment with its UI with the long term goal of possibly integrating it into his music player, ready-player.

Ytr is still at an early stage of development and will probably change as Ramírez gets more experience with it. It’s not yet in MELPA, of course, but you can get a copy from its GitHub repository where you’ll find installation instructions as well as a command summary.

If you have any interest in playing YouTube radio from within Emacs, take a look at Ramírez’s post and the ytr GitHub repository.

Update [2026-06-24 Wed 10:08]: Álvaro Ramírez reached out to me offline with a clarification. What ytr actually does is download the audio track from any YouTube video. As Ramírez says, often the video portion is secondary to the audio. I’ve noticed that that’s especially true for older recordings where the video portion may consist simply of a picture of the album cover or the artist.

Posted in General | Tagged Emacs |

Bozhidar Batsov has an excellent post that considers structured editing using builtin Emacs commands. It turns out that all those commands (like forward-sexp) that you think of as Lisp-specific commands work in many other modes. The secret is that the target mode has to tell the commands how to find structure boundaries.

There are several ways of doing that. The oldest is to use the mode’s syntax table but that doesn’t work if the structure is bounded by things like structure … end. The more modern method is to provide functions that can find these boundaries and, of course, the most modern is to use Tree-sitter with an actual grammar of the target language.

Pay particular attention to the Ctrl+Meta commands. If you’ve done any Lisp programming, they’ll be familiar but they’re useful for a lot of other languages—even plane text. For example, I use Ctrl+Meta+Space all the time to progressively mark words in a text buffer. It’s a bit easier than using Ctrl+Space and then some motion command to do the same thing.

As Batsov says, the Ctrl+Meta commands keep getting smarter as more major modes teach them about their syntax. His post is full of good information that I haven’t mentioned here so be sure to head over and read it.

Posted in General | Tagged Emacs |

Charlie Holland has a followup to his post on Emacs Help that I wrote about the other day. It’s a reconsidered, condensed version of the original post. As Holland puts it,

This is a condensed version of my very long June Emacs Carnival post on the same topic. I wanted to make this as I felt it would be more intuitive for beginners, who are most likely to benefit from learning Emacs’s auto-discovery features.

It actually is more useful both for n00bs and experienced users alike. The best example of that is his explicit calling out of what he calls “the prefix trick”. The idea is that there are a handful of prefixes that begin many help commands. One example is describe- that begins all the help commands that describe something: describe-function, describe-variable, etc. The “trick” is that you can type Meta+x describe and then Tab to get a list of all the describe commands. That’s something that most of us know implicitly but it’s useful to have it pointed out explicitly.

The other useful fact, which I wasn’t aware of, is that Meta+x which-key-show-top-level will show all the commands without a prefix.

The point of Holland’s followup is that you don’t need to memorize a lot of arcana to use the Emacs Help system. If you know the prefixes to use with Meta+x and Ctrl+h Ctrl+h to bring up the Help cheat sheet, you’re good to go.

Update [2026-06-23 Tue 11:15]: Added link to followup.

Posted in General | Tagged Emacs |

Rahul M. Juliato has an informative post on what’s coming in Emacs 31. Juliato doesn’t mind living on the edge and has been tracking and using Emacs from the Master and emacs-31 branches. He says he likes to know “what’s in the box” and the way to learn what’s coming is to is to live in it. That’s a little too exciting for me and perhaps for you but Juliato’s post gives us a view of what to expect.

The list is a long one and his post reflects that. It’s a lengthy post but it does a good job of describing what to expect. The thing he’s happiest about is that with this release tree-sitter “just works”. Now installing new grammars is pretty much automatic and there are grammars for more languages.

For those of you who have to—or for some reason, choose to—use Markdown instead of Org mode, the new markdown-ts-mode will be a welcome addition. The new mode has an Org mode feel so Org users will feel comfortable using it.

For those of you who like the completion system making your mind up for you, there are many enhancements to eager completion. That definitely not something I would want; I hate having the system change what I’m typing without my asking for it.

There are several other changes. Check out Juliato’s post for the details. It looks to be a nice release with plenty of improvements. People like Juliato help the development process by thoroughly testing new features for bugs and for suggested improvements.

The minions are insisting that I let you know that you can and should view Juliato’s post in light mode by flipping the switch at the top of the page. Sorry for the boring announcement but none of us wants to deal with disgruntled minions.

Posted in General | Tagged Emacs |

Yusuf Aytas has a great post that explores the difference between a vibe coder and a software engineer. He plays it straight and says, basically, that vibe coding may be fine for a proof of concept or for a one-off internal job but as soon as you get to the merge stage you need a system engineer. The issue, he says, is ownership. Once code is merged, someone has to own it, understand it, and maintain it. That’s most often impossible with vibe code. Usually, no one can understand it or its implications and it’s certainly not maintainable.

That’s the polite version. Mine is a little less politic. Every time I read about vibe coding, a story from long ago comes to mind. Back when exploits were mainly a nuisance from young people with too much time on their hands, even younger people—aspiring to be seen as “hackers”—would take an exploit binary that did some mischief and ended by announcing “You’ve been hacked by Dufus” and do a string replace so that the announcement said, “You’ve been hacked by Goofus”, Goofus being their name. Then they claimed ownership of the exploit.

These people were called script kiddies and held in universal contempt. They had no knowledge of coding, let alone of engineering an exploit. People who restrict their activities to vibe coding and claim to be engineers strike me in the same way. Note that I’m not saying using vibe coding when it’s appropriate is a bad thing. Used properly it’s just another tool but if your activity consists of vibe coding and only vibe coding, please don’t call yourself a software engineer; you aren’t.

Posted in General | Tagged RMF |

Charlie Holland has a very nice contribution to June’s Emacs Carnival about underappreciated Emacs builtins. His post is about the Emacs help system and how you can use it to learn everything about Emacs. It’s a commonplace to say that Emacs is self-documenting but that’s little more than a slogan. Holland takes a long look at what that actually means.

He begins by noting that the help system is self-recursive is the sense that you can ask the help system about the help system. You simply call the help-for-help command intuitively bound to Ctrl+h Ctrl+h. If you’ve never tried it, try it now. It gives you a nice listing of every help command.

Once you invoke help for a certain command or variable, you get a buffer containing a description of the command or variable as well as links to related commands/variables and the source code of the command so you can see exactly what it does and how it does it. You can discover what command a shortcut calls or what the shortcut for a command is with a simple help call.

There are a bunch of other aspects to the help system. You can, for example, get a listing of what your last commands were, complete information about the character at point, the current value of a variable, the current mode, and lots more.

For discovery, there are the apropos command and its siblings to help you find what you’re looking for even if you have no idea of its name. You merely need to have a general description of what it does. Fuzzy completion on command invocation (Meta+x) helps you find the right command even if you have only a vague idea of its name.

Hoplland’s post is long and has a lot of information but it’s one that every Emacs n00b—or more experienced user, for that matter—should read. In Holland’s terminology, it’s the first node in the Emacs knowledge graph.

Posted in General | Tagged Emacs |

Over at Ray on Emacs, Raymond Zeitler writes about the Emacs Diary for the June Emacs Carnival. The June topic is underappreciated Emacs built-ins and for Zeitler that’s Emacs Diary. He was a little disconcerted at first by being offered a blank screen for each entry. He wondered where his previous material went but he came to appreciate the fresh start that that blank buffer gave him. He goes on to describes some of the functions and capabilities of Diary.

I recently started keeping a personal journal too and considered using Diary—it was, of course, going to be written in Emacs in any event—but decided to simply use Org mode instead. I have an Org capture template to start a new entry—just like Zeitler’s method—but I can, of course, just bring up the journal Org file directly to see or edit anything.

I’ve found that this works well for me. I don’t write in my journal everyday, just when something worth recording happens, so I don’t care about things like when the sun rose or set, what the temperature was on that day; just what happened that I felt was worth remembering. Of course, if I did care about such things it would be easy to arrange to add them.

Or I could just use Diary. That’s the beauty of Emacs: you can make it do pretty much whatever you need it to and very often what you need is already there.