Irreal

A few days ago, Chris Maiorana wrote an article, The 10-Commit Rule: how git version control can improve writing quality, about how he uses Git and Emacs to regulate his writing workflow. The idea is to track how many changes he’s made to his text since the last commit and to stop and review his work when he reaches about 250 changes, deletions, or additions. The advantage of this system, he says, is that it keeps you from burning out in an initial burst of enthusiasm by forcing you to stop periodically and see where you are.

To help him with this, he has a mode line display that shows him how many changes he’s made since the last commit and how many commits he’s made today. It seems like a system that could be useful to many writers. The problem is, he didn’t explain how he got the numbers for his mode line display.

Now, however, he has a new post that explains how he generates that display. The TL;DR is that he interrogates Git to get both numbers. The number of commits is pretty easy, of course, but getting the number of changes is a bit trickier. Basically, he runs a script that does a git-diff and pipes the results through grep and wc to extract and count the “words” that have changed. To keep from running the script continuously, he caches the results and updates them only every 30 seconds.

I’m not sure I’d like using his exact system but I must admit that I do pretty much the same thing without the software assist. Every so often, I stop, reread and edit what I’ve written, and, if I remember, commit what I have so far. As any writer will tell you, there are as many writing methods as there are writers so whether Maiorana’s method works for you will be a matter of your preferences.

Álvaro Ramírez has a new Bending Emacs video up. This time it’s about his agent-shell app that serves as uniform Emacs interface to LLM agents supporting the Agent Client Protocol (ACP).

I’m not interested in LLM technology so you almost never see an Irreal post about it. I don’t know—and therefore have no opinion on—if it’s something real or just another venture capitalist fever dream. Still, if you are interested in LLMs, it’s nice to have an app like agent-shell that provides a uniform interface to most (all?) of them.

There’s a huge number of options and details to negotiate so an app like agent-shell is a real boon. Almost none of those options involve picking which shell you want to use. You simply choose one from a list of supported shells and work within that shell for the rest of your session.

There are way too many details for me to cover here. The video itself is 36 minutes, 34 seconds so there’s a lot of content to cover. If you are interested in LLMs, and especially if you use more than one, you should definitely watch this video and download agent-shell. It’s available on Melpa so installation is easy. Like all of Ramírez’s work, agent-shell seems like a well engineered app and it’s free so you have nothing to lose by trying it.

Emacs has a couple of builtin ways of dealing with separate windows that are looking at the same file. The default method is to simply “open” the file again in a separate window. In this case you have two views into the same file. The windows may be looking at different parts of the file but any change made in one window appears in the other as well because both windows are using the same buffer.

Alternatively, you can open the second window by cloning the first buffer. That creates a second buffer with the same text and properties but they are distinct buffers that can have different point values, different narrowing, different major modes, different markers, different overlays, and different local variables. Nevertheless, any text or text property change made in one buffer is reflected in the other. Take a look at the Emacs manual for the details.

You’d think that those two options would cover whatever you needed to do but Sacha Chua has a post that describes a case not covered by either. In this case the user wants to display an SVG file in one window and the XML that generates it in another. The problem here is that the image is displayed with text properties so toggling the display in one window will cause it to affect the other window as well even if the other window is a cloned buffer.

Chua shows how to solve this by writing a bit of Elisp. The TL;DR is that she bypassed the code that checks if the target file is already opened in another buffer and simply creates a new buffer unconditionally. Of course, now you have to worry about syncing the text between the two buffers. Chua solves this by turning on global-auto-revert-mode so that when one file is saved, the other gets updated.

I’m always prattling about how having the Emacs source available from within the executable image coupled with the ability to make on the fly changes is one of Emacs’ magic powers. Chua’s solution is a nice example of this.

I saw this post from mbork on paragraph filling. It’s a nice post and I’ll probably write about it later but today I want write about something else he mentioned in his post: unfill.el. It’s from Steve Purcell and has been around for a couple of years but I somehow missed it.

Most of my Emacs buffers are set to wrap text, which is usually what you want to do but for writing buffers, such as my blog posts, I use visual line mode and don’t want any filling. More often than you’d think I would, I find myself writing a blog post or some other prose and discover that I’m filling text lines.

My usual solution to this is to let the line length to a large value and call fill-paragraph. That’s not very hard but it’s a pain and I should have automated it long ago but my laziness kicked in and I never did. Happily, Purcell has done this for me. It does the same thing I did manually but with a single key press. Even better, he provides the unfill=toggle function. If you call it once, it fills the paragraph. If you call it again, it unfills the paragraph. That’s nice because you can bind unfill-toggle to Meta+q, or whatever you usually bind the fill command to, and get both commands for the price of one. In the mean time, I’ve installed unfill.el and bound Meta+q to unfill-toggle. One more tiny nub sanded down.

Update [2026-01-17 Sat 15:57]: unfill.org → unfill.el

Chris Maiorana has decided to take the old joke about Emacs being an operating seriously. Or at least at face value. He has planned a series of posts where he compares the Unix way of doing things to the Emacs way.

The first post in the series compares directory listings. That’s a fundamental function for any operating system, of course, so it makes sense—if you’re comping operating systems—to see how they handle that task.

Maiorana’s answer is to look at the various outputs from the Unix ls command and compare them to the results from Dired. There’s not much to compare, of course, because the Dired listings are generated from the underlying ls command. The difference is how you handle options. In Unix this is done through command line options. In Emacs, you change the Dired listing after it’s first displayed with buffer specific commands as usual in Emacs.

The real difference is in the power that Dired provides. You can’t do anything that you couldn’t do in Unix but with Dired it’s all one command. You think of the listing as just another Emacs buffer that you operate on in the usual ways or perhaps bring bespoke commands to bear.

I don’t really believe in the Emacs as OS paradigm—although I sometimes pretend I do. A more accurate description is that those of us who live in Emacs tend to treat it as if it were a shell. With Emacs, there is seldom any need to drop into an actual shell to get things done and even if you do, Emacs can provide you with several including it own eshell.

I’ll be interested to see Maiorana’s subsequent posts on the subject. I’m interested in exploring the extent to which Emacs can be claimed to be an operating system.

One of the problems with the ELPA package manager is that you never know what you’re getting when you upgrade. The package manager tells you what packages can be upgraded and you can choose to upgrade or not but you don’t know what’s changed.

Happily, a new feature has just been committed. Now you can examine a diff between the old and new versions to get an idea of what has changed. It’s not ideal if you can’t read Elisp but at least those who do read it can get an idea of how the new version differs from the previous.

It’s not a big thing, I suppose, but it does show how Emacs is continuing to improve and make its users’ lives better. This new capability probably won’t be available until the next release but it’s something to look forward to.

Matthias over at Ahoi Blog makes an observation that I’ve also made many times: Discussion about Emacs startup times ends as soon as you run Emacs as a daemon. The startup is instantaneous and if you prefer a Vim-like way of operating where you start and stop Emacs each time you need it you can have it. Of course, Emacs doesn’t really stop. It’s still running as a daemon and will pop up a new frame for you whenever you need one.

With this model, the Emacs startup time is absorbed into the system boot time, which presumably happens rarely. The question is, how to get the daemon started. If you want to have it happen at boot time, the exact method depends on your operating system.

Matthias shows how to do this in Linux. It’s a little finicky because of systemd but really just amounts to making an entry in a configuration file. You can see the details in his post. The other issue is how to start, stop, and interact with the Emacs daemon when it’s running. Matthias has a simple script that automates all that so that you don’t worry about the intricacies of systemctl and journalctl.

The other possibility is to simply never exit Emacs. That’s what I do. I run it in its own workspace so I don’t have to worry about hiding it when it’s not in use. I also start server mode so that I can instantly pop up a frame (either GUI or terminal) if I want to for some reason. I really do think this is the best solution but others obviously disagree. If you like to bring up your editor when you need it, quit when you don’t, and your editor is Emacs, you should take a look at Matthias’ post. It will tell you how to run Emacs the way you want to and you’ll never have to think about startup time again.