Irreal

Bsag over at but she’s a girl… has an interesting post on what she calls the Emacs from scratch cycle. She’s noticed that she goes through a roughly 3-year cycle of starting with a vanilla Emacs configuration, moving to one of the Emacs frameworks such as Doom, and then back again to vanilla Emacs. It is by no means a waste of time. In each cycle she learns a bit more about herself, her editing needs, and Emacs. As I put it before, it’s like tending a Japanese garden: a lifetime spent moving towards perfection but never achieving it.

In her latest cycle, she decided to resist adding packages unless she was irritated by not having their capability. Once installed, she makes a point of evaluating whether or not they actually improves things and deletes them if they don’t. She was, she said, surprised at how few packages she ended up keeping. I’m sort of like that except that I don’t have her culling discipline. I’m slow to add packages but once installed, I seldom delete them.

Bsag compares the process to making her own clothes. When you do that you end up with clothes that fit comfortably, are exactly the right length, are made from the fabrics you prefer, and even have the pockets exactly where you want them. But, making your clothes is, you know, a pain. It’s a lot of work and sometimes it seems easier to just go out and buy a premade garment.

My innate inertia and, let’s face it, laziness has saved me from this. I started out with a bare Emacs and added configuration items when I found I needed them or discovered something that appealed to me. That configuration has been expanding ever since. As I said, I seldom bother to prune it. Nor have I ever felt the need to declare Emacs configuration bankruptcy and start over. Currently, my configuration is about 2,500 lines so it’s still under control and probably will be for the rest of my life. I hardly ever restart Emacs and when I do it starts quickly so I see no need to change my ways.

Bsag has an interesting perspective. It’s worth spending a few minutes on her post.

If you’ve been around Irreal for as little as a few months, you know that I’m a fan of Charles Choi’s “Casual” utilities. They’re all basically the same. They add a transient menu to Emacs utilities such as Calc, Isearch, Info, and others so that you can have access to the more obscure subcommands of the utilities without having to remember key shortcuts that you hardly ever use.

I’ve found the Calc and Casual Info menus especially helpful since they have lots of subcommands that are useful but that I don’t use all that often. Others may find some of the other Casual menus useful.

Choi started out with the Isearch and Calc packages and probably didn’t realize that the idea could be extended to many other Emacs subsystems. Now that these packages have been a success, Choi realized that those early packages weren’t named in a manner consistent with the later ones. He therefore has announced some name changes. If you aren’t using the Calc or Isearch packages you have nothing to do. If you are, you will have to update your configuration to reflect the changes.

The plan is that the changes will occur on [2024-06-16 Sun] (that’s THIS Sunday) so you’ll need to have your configuration in place after that. I’ve updated my init.el to reflect the new Calc name but it’s still commented out. Given that all goes as planned, I’ll uncomment the new configuration on the 16^th, evaluate it, and be up to date.

Gene Goykhman, like a lot of Emacs users—or simply computer users, for that matter—hates dealing with fussy details while working on his computer. One of his complaints in particular is that there are too many confirmations in some of his frequent tasks.

For example, when quitting and saving an Ediff merge, he has to respond to two separate confirmations. His solution was to write a wrapper function that replaces the confirmation queries with #’always. It’s pretty simple code and easily understandable. He binds it to a keystroke to unconditionally quit whatever function he wants to quit without the bother of confirmations.

This is yet another example of the difference between Emacs extensions and the plugins used by other editors that I wrote about previously. You almost certainly couldn’t make this change with an editor that relies on plugins.

In any event, if you’d like to get rid of some of the superfluous confirmations in your Emacs workflow, give Goykhman’s post a read.

Just a quick note to share something that I’m just learning after more than 15 years of using Emacs. I am, of course, aware that Viper and Evil are modes that emulate the Vi family of editors. It’s a way of letting immigrants from Vi/Vim retain their muscle memory while enjoying the superior working environment of Emacs.

I had always assumed that Viper is an older emulation that has since been replaced by Evil. That’s sort of correct but not quite precise. Over at the Emacs subreddit, CorysInTheHouse69 asks why, given that Viper is builtin, people prefer Evil over Viper. The answers surprised me.

It turns out that they actually have different aims. Viper is a Vi emulation while Evil is a Vim emulation. Unless you’re the type of person who prefers the original Vi to the “new-fangled” Vim and its siblings—and there are such folks—you probably want Evil, which offers a very faithful Vim emulation.

As a side note, several of the respondents note that the distinction between built in and third party packages is more political than practical these days. As I wrote the other day, Emacs makes no distinction between code that is built into Emacs and that which is added on. It can not, in fact, tell the difference. It is, as they say, turtles Elisp all the way down.

Regardless, if you, too, were ignorant about the different purposes of Viper and Evil, now you know.

After my post on a Linux specific problem and Emacs I feel entitled to bring up another macOS specific issue. This problem is brought to us by Alvaro who explains that it’s possible to combine trackpad scrolling and certain keystrokes that result in a spontaneous font size change in the current buffer. Depending on whether you scroll up or down, the font may become larger or smaller.

The font size changes get triggered when Ctrl is pressed while scrolling. It’s tempting to say it serves him right for using the mouse in Emacs but, as Alvaro says, the MacBook trackpad is especially convenient for scrolling and easy to get used to when in one of those other applications. It’s right there below the keys and so easy to reach with a thumb that one can almost pretend they’re not using the mouse.

For a while, Alvaro solved the problem by simply reloading the file with Ctrl+x Ctrl+v but then someone showed him how to stop Emacs from changing the font sizes to begin with. If you’re having this problem, head over to Alvaro’s post to see to solution. Better yet, keep your hands off the trackpad.

I have, from time to time, written Emacs posts that are specific to macOS. Lots of folks use macOS so I don’t apologize for that but lots of folks use some flavor of Linux too so it’s only fair to recognize some Linux specific Emacs uses as well.

Lars Ingebrigtsen is a Linux/Emacs user who likes things the way he likes them and who has no patience for systems that don’t meet his needs exactly. He has an interesting post that lists three such problems:

1. His laptop goes into power save mode sooner than he’d like.
2. When he closes his laptop cover it goes to sleep like most laptops. He doesn’t like that for reasons you can read in his post. He wants it to turn off his screen and nothing else.
3. When he turns off his Bluetooth speakers, he wants his laptop to stop playing music.

He noticed that what all these problems have in common is that he wants to react to some hardware event in his own way, not in the way the system developers thought best. His solution to this is to use D-Bus to listen for the requisite events and notify him when they occur. From there, it’s a simple matter to react in the appropriate way.

What may be surprising is that all this is written in Elisp. He doesn’t show the code in the post but does provide a link to it. The code is straightforward and there’s not much of it. It is, as he says, specific to his needs but should be easy to adopt to any user’s needs.

Sadly, this is mostly useful for Linux users although there is a port of D-Bus for macOS. I’ve never used it so I don’t know how well it would work for an application like this but it’s easy to install with Homebrew and worth checking out if you have problems similar to Ingebrigtsen’s.

Over at Lambda Land, Ashton Wiersdorf opines on what he considers the best Emacs packages. You may agree or disagree with any particular choice in his list but it’s hard to argue that his choices are not reasonable.

His list starts with Magit, Org Mode, and Avy, which should, in my opinion, be on everyone’s top 5 (or so) list but that’s low hanging fruit. Next on his list is Embark, Eat, and Jinx. I use Embark and like it but it’s not a must have for me. I really liked the idea of eat, but after I installed it, I never used it so it was a dud for me. One of the things everyone loves about it is how fast it is but the speed of all the Emacs terminal emulators seem fine to me. I’m not familiar with Jinx but it seems like it’s something worth checking out.

His next three packages are Vertico, Consult, and Corfu. I don’t use any of these. I much prefer the Swiper/Ivy/Counsel package. It does pretty much the same things and I’m used to and happy with it so I’m not inclined to change.

Regardless of my predilections, these are great packages and worth taking a look at to see if they would work for you.