Irreal

Protesilaos (Prot) has an excellent post on keyboard ergonomics for Emacs users. He considers various strategies for making Emacs commands easier to use and less likely to cause RSI damage. He considers everything from split keyboards to evil-mode.

He says he has both a split keyboard and a keyboard with a normal form factor. He says that the split keyboard is not a magic solution and that what works best for him is to configure “one shot modifiers” where the modifier is simply pressed—but not held down—before the key it modifies. So, to use his example, Ctrl+x is typed by tapping the Ctrl key and then the x key.

Along with that he suggests ordering the modifier keys in a way you find comfortable. The most important thing, he says, is to keep the Ctrl key close to the space bar so that you can use your thumb to press it. It’s also important to have the modifier keys located symmetrically so that, for example, you can use either hand for the Ctrl key.

As for the common advice to map Caps Lock to Ctrl, Prot says that’s okay but that it encourages the bad habit of always using your left pinky for Ctrl.

There’s a lot more information in Prot’s post—including how to configure one shot modifiers—so be sure to take a look at it.

I’ve been incredibly lucky. I use a standard keyboard, map Caps Lock to Ctrl and don’t have any symmetric modifier keys. Nonetheless, I haven’t suffered any RSI problems despite spending the majority of my day at the keyboard. But, as I say, I’m lucky. The smart thing to do is to read and head Prot’s advice.

Protesilaos (Prot) has a new, interesting package available: buffer-to-pdf. It does just what its name suggests. It takes the current Emacs buffer and exports it to PDF preserving things like theme, and font characteristics.

It’s easy to use. You simply call buffer-to-pdf and you get a PDF of your current buffer. You can specify the orientation—portrait, landscape, or current window—for the output but that’s the only choice you have to make.

The most complicated thing about the package is its pagination. If you have an Org file, each headline is a new page. The idea is to turn it the org file into a set of slides. Again, this all happens automatically.

For a simple text file, buffer-to-pdf paginates at screen borders. That seems like a natural thing to do and allows a certain amount of control over where the page breaks occur by adjusting the window size.

Finally, you can specify explicit page breaks by inserting a form feed (^L). Prot’s video doesn’t make clear how the form feeds interact with the window boundary heuristic but, as Prot says, the best way of thinking about buffer-to-pdf is as a screen capture that produces a PDF. It’s a perfect way to share an Emacs buffer with someone else.

If you’re interested in this package, take a look at Prot’s video at the above link. You can check out the package’s Git repository here.

Sean Whitton writes to say that the Emacs development team is planning to start the Emac 31 release process next week. That means that they will cut the Emacs 31 branch and start the process of testing and refining it in preparation for the final Emacs 31 release.

I really like how the development time is handling releases lately. They plan on a major release about once a year and in between time issue updates to fix bugs or problems in the latest major release.

If you follow the Emacs Devel mailing list, you’d think that the developers’ full time job is Emacs and that they have no family. It’s incredible how much unpaid time these people devote to Emacs
for the benefit of us all. As I always say, if you find yourself in a bar with any of them, the drinks are on you. These guys really are heroes.

Here are a couple of quickies. Neither one requires much exposition on my part but they are both interesting. In the first, Prot shares what he considers decent default settings for Emacs. Naturally, I don’t agree with all of them but they’re an excellent start for your init.el. For example, I’d be more likely to prefer Melpa over Gnu Elpa, and I prefer Swiper to Consult but that may be simply because I’m used to Swiper and it works well for me.

Most of the rest of his choices I agree with or at least am agnostic about. That’s the thing about Emacs, you get to choose what works best for you.

The second quickie is a post from Charles Choi that discusses bulk search and replace commands in Emacs. Choi begins with reviewing regular expression syntax. That’s important because some Emacs command use the builtin regexp syntax and others call various versions of grep, which, of course, have their own regexp syntax.

As usual with Choi’s posts there’s a lot there and it requires careful reading but it’s worthwhile. As Choi says, the Emacs bulk search and replace commands make possible workflows that would be harrowing in other editors but they’re also difficult to discover. His post is intended to remedy that.

After reading the sad news that Chris Wellons is abandoning Emacs and the Emacs packages he developed one of my first concerns was for Elfeed. It’s the RSS reader that I depend on everyday for my research and news curation. Wellons will be missed for many reasons but his stewardship of Elfeed is the most important one to me.

I’m all but certain that Wellons will find good hands in which to entrust the future of Elfeed but as I learned in the Boy Scouts, it pays to be prepared. Serendipitously, I stumbled upon this post from Dave’s Blog that mentions he moved from Elfeed to Gnus. The post is about a solution he found for following links referred to in the RSS summary but I was more interested in his use of Gnus in place of Elfeed for RSS.

I’ve considered, off and on, moving to Gnus but I’m really happy with mu4e for email and elfeed for RSS and Network News is, sadly, no longer important so moving to Gnus didn’t make much sense to me. Now, unfortunately, I may have to think about it. Gnus is a powerful complicated program and it seems a shame to use it just for RSS but if worse comes to worst it’s nice to have a mature and reliable fallback available.

As I said, I’m pretty sure Elfeed won’t have any problems finding a new maintainer who will sustain its high quality but it’s nice to know that if I need it, there’s a viable, Emacs-based solution available.

I recently opened my feed to discover this post from Chris Wellons. The TL;DR is that Wellons, after 20 years, is abandoning Emacs for Vim. Folks do that, of course, but Wellons is special because he’s been a prolific author of Emacs packages including the absolute best RSS reader, Elfeed that I use everyday and depend on for my Irreal research.

Over the years, I’ve interacted with Wellons several times and always found him to be personable, engaged, and shockingly smart. He’s exactly what you want in an interlocutor: informed but not inextricably bound to his opinions. He was always interested in the truth and willing to be persuaded by facts.

By now, this has been all over the Internet and Sacha has already covered it on Emacs News but I wanted to add my appreciation for Wellons and everything he’s done for the Emacs community. I and the rest of our community can only hope that he returns from the dark side but in any event, we wish him well and thank him for all he’s done for us.

In the meantime, he still has some packages in need of a new maintainer. There’s a list on his post. If you’re interested, get in touch with him.

Randy Ridenour has an interesting post on Emacs and sunk costs. His post is in reaction to the idea that using Emacs requires a lot of learning and customization and that those efforts are sunk costs. That is, they’re costs that you’ve already paid and will never get back. All of that is true and Ridenour agrees.

What he doesn’t agree with is the conflation of “sunk cost” and “the sunk cost fallacy”. The sunk cost fallacy is, roughly, the idea that you should continue with some activity simply because you have so much invested—so much sunk cost—in the activity. Everyone has experienced it. Ridenour gives a common example that we’ve all dealt with: the refusal to hang up while waiting to talk to a representative on a support call because we’ve got so much time already invested.

The proper way to think about sunk cost is to imagine you got where you are for free and decide what you should do next without considering how you got there. In the case of Emacs, Ridenour says, that means to imagine you’ve never used an editor and that the expert you consults tells you that he can give you

1. A ready to use editor that works well but requires you to do things its way or
2. An editor that is custom built for you, that works the way you want it to, and that has commands that only you care about.

The rational choice is obvious. That’s why Emacs users keep using Emacs. Not because they have so much invested in it but because Emacs is the best editor and can be adjusted to continue being the best editor as their needs change.