Irreal

Well, not really prodigal, but the return—nonetheless—of a son assumed lost. Michał Sapka has a blog post about his return to Emacs. A while ago, Sapka left Emacs for Vim and the shell. He liked them but realized that Emacs really is different.

The way it’s different is telling. Although you can do anything in Vim and shell, Emacs is different. As Sapka puts it,

It’s not that nothing stops you from connecting Mastodon.el, Magit and Mu4e, it’s that it’s natural.

Because all of Emacs is exposed to the user, it’s easy to modify it to fit your workflow and string together disparate applications in ways that their authors never intended. Sapka makes the same point that Irreal and others have made: it’s not that Emacs has an extension language, it’s that Emacs’ source code is modifiable on the fly from within the application itself at run time. It’s a whole different thing.

Sapka admits that there are problems but says that they are solvable. Depending on your work environment, solving them may be more or less difficult but they remain solvable.

In any event, Sapka has returned to Emacs because, in the end, nothing else provides the same power and flexibility. He ends his post by noting that he’s—sort of—combined the power of Emacs and Vim by adopting Evil mode.

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.