Irreal

Does Emacs run slower on macOS than it does on a similar machine running Linux? I don’t know. I’ve been running Emacs almost exclusively on macOS for somewhere around 17 years so its performance on macOS, whatever it is, seems normal to me.

Over at the Emacs reddit, staff-engineer says that he runs it on both macOS and on Linux. The Apple machine is, in fact, more powerful than the Linux one but is nevertheless less performant when running Emacs and staff-engineer wonders why.

He received several excellent answers that are definitely worth reading but I especially like the one from totbwf who explains that a large part of the problem is that macOS uses a tiny size for its pty buffers and that this can significantly slow down Emacs when it calls an external process using a process-connection-type of pty. His solution to this is to simply advise functions calling start-process to use pipes instead of ptys. He says that this can speed up these actions by a factor of 10. For Magit, he says that you can get the same result by simply setting magit-process-connection-type to nil.

Even if you don’t want to add a lot of advises to your configuration, it may be worthwhile making this one simple change to Magit if you use it a lot.

To be honest, I have no idea if these fixes will work or not but they’re easy to try if you feel Emacs is too slow on macOS. If changing the connection type helps, I would think that someone would fix it in Emacs core for macOS installations. It doesn’t sound like it would be too hard but one of the problems is that there are few Apple users helping with development.

You’ve all heard me moan many times about my failure to bring my last remaining significant application—Web browsing—into Emacs. There are some solutions but none of them come close to being sufficient. If you want full featured browsing, you’re mostly restricted to Safari, Firefox, one of the niche browsers, or the privacy violating Chrome and whatever Microsoft’s browser de jour is called.

Still, there is EWW, which some people find some sufficient for a subset of browsing tasks. Charles Choi is one of those people so naturally he’s made using EWW easier by adding Casual EWW to his Casual Suite.

You can read his announcement for the details but, as usual, it’s mainly a set of transient menus that make discovery and remembering obscure commands easier. As I’ve said before, even if you need only some of the apps, it’s worthwhile installing the Casual Suite.

I’ve written before that one of things I love about Elfeed is that it keeps a database of all your feed entries. That makes it easy to find earlier content if you need to revisit or reference it for some reason. It has an excellent search capability that makes this mostly painless.

Punchagan over at NOETIC NOUGHT has a sobering tale about losing his Elfeed database. He thinks it probably happened during a system crash that occurred at the same time his Elfeed database was being saved. Depending on how you use your feed, that may be more or less disastrous.

If you depend on your feed for research, the loss would be serious. Punchagan uses his Elfeed all the time so he decided to automate the backing up of Elfeed’s database. He shows the code in his post so you can take a look. It’s pretty straightforward. Whenever a tag changes or a new entry is added, he schedules a database save and backup to Git.

If you’re an ordinary user, you may not need such immediate backups. You could for example, schedule a backup once or twice a day so even if you lost the active database the loss would be minimal. On the other hand, if you really depend on your feed, Punchagan’s solution may be just what you need.

Despite what I wrote last time about tmr, I’ve come to realize that deep down I’m a timer nerd. As my family will tell you, I can be anal about following directions precisely. If the recipe says to beat the eggs for 30 seconds, I feel uncomfortable if I don’t have some way of measuring those 30 seconds more or less accurately.

Once I got my iWatch with it’s excellent and easy to use timer app, my inner timer nerd was released and now it seems I’m always using a timer for some reason or another. Given that I spend a huge amount of my time staring at a computer screen—most often in Emacs—it makes sense to be able to set and manage timers there too.

Prot to the rescue. His tmr package is just what you need to set and manage timers from within Emacs. He’s got a great video up that demonstrates tmr and its capabilities. It’s a lot more than just, “Beep after x seconds”. You can have multiple timers that you can set to fire after a given number of seconds, minutes, or hours. You can also set the timer to fire at a certain time.

You can add descriptions to each timer and display them all in a grid layout to see how much time, if any, is remaining in each timer, when it started, and when it will expire. You can also arrange to display the time remaining on each timer in the mode line if you like.

See Prot’s video for all the details. The video is 14 minutes, 32 seconds long so it should be easy to find time for it. Installation and configuration is easy so give it a try if you are also a timer nerd.

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.