Irreal

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.

For those of you who like using your mouse with Emacs, Charles Choi has a post you may find helpful. In it, he lists some keybindings that are helpful when using a mouse in Emacs. I famously eschew the use of the mouse wherever possible—not just in Emacs—so I have no worthwhile opinions about matter and I’m not going to comment on his bindings. In any event, I long ago mapped F10 to Calc so none of it applies to me anyway.

Still, I recognize that many of you do like using the mouse so I thought I’d point out Choi’s post for you.

James Cherti has an excellent post describing how to set up a universal folding system. Folding is one of those things that I’m equivocal about. I use it all the time in Org files and couldn’t live without it. On the other hand, I’ve never seen the need for folding in code files. Sometimes it is convenient to focus on a single function but in those cases I simply narrow to the function.

Perhaps my problem is that every type of file seems to have its own folding engine with different commands and bindings. Regardless, Cherti definitely does like folding in his code buffers and like me with Org files, couldn’t live without it.

His post explains his system with dealing with folding in various types of buffers. The TL;DR is that he uses kirigami as a front end to provide a uniform interface to the myriad of folding engines. That’s pretty nice but you have to tie it to the back end engines.

That’s where Cherti’s post really shines. He provides the hooks for a large selection of file types. It’s not always obvious which engine you should use for a given file type and Cherti explains why he thinks each of his choices is the correct one.

The nice thing is that once you’ve set up and learned kirigami, you can add folding for whatever files you need simply by setting a hook. Kirigami allows you to set your own bindings for the commands so even learning Kirigami is simple.

If you’re more like Cherti than like me, and want folding for as many of your files as possible, take a look at his post. It’s really easy to set up and gives you all the folding power you’re apt to need.