Irreal

Last month, I wrote about Charles Choi’s post on the the on package-install-upgrade-built-in variable and how it controls the upgrading of builtin packages. The TL;DR is that when it’s set to t, package.el treats builtin packages as if they had been installed like any other 3^rd party package for upgrading purposes.

My first inclination was to wonder why anyone would not want to have it set to t. I could imagine some outlying cases where it didn’t make sense but mostly I’d have expected that upgrading builtin packages was what most users wanted.

Apparently not. Over at the Emacs subreddit, jonas37 asks if people are setting package-install-upgrade-built-in and the comments are revealing. It’s hard to imagine the answer would be controversial but lots of people have strong feelings on the matter.

Take a look at the comments to see what I mean. The answer, as it usually is, is that “it depends”. In short, it’s hard to automate the decision. Sometimes you want to upgrade the builtins and sometimes you don’t.

It’s easy to take the position that your editor, whatever it is, should take care of things for you, but people who do take that position are the first to complain when the algorithmic decision is not to their liking. Sadly, sometimes we just need to engage with Emacs and tell it what we want it to do about upgrading our packages. For many cases. setting apackage-install-upgrade-built-in to t is probably the right decision but sometimes not. It, as they say, depends.

Charles Choi is announcing another member of his casual suite: Casual Agenda. Like the other members of his suite, Casual Agenda provides a Transient driven menu that helps you navigate the arcane functionality of Org Agenda View.

I say “arcane” because although it’s easy to use Agenda View to simply list the content of the target files, there’s a lot more functionality hidden in obscure commands that even if you know they exist are hard to remember. Remembering the commands is even harder because Org makes them context sensitive.

Take a look at Choi’s post to see the menus and how they work with each other. It’s a nice system and probably worth installing even if you don’t use the commands often. Especially if you don’t use them often.

I know these command exist but I can never figure out how to access them so I’m really glad to see this latest addition to Choi’s suite. If you’re in the same situation, you should consider installing Casual Agenda.

You can, alternatively, simply install Casual Suite to get all the apps in the collection. This has the advantage that you automatically get additions to the suite when Choi adds them. All the apps have to be invoked explicitly so they never get in the way. If, like me, you follow Choi’s recommendation to bind them all to Ctrl+o, you need only remember a single command to bring up the appropriate menu when you need it.

As I’ve said before, I really like this set of applications and recommend you install the ones you need or possibly just install the entire suite.

The ever industrious Protesilaos Stavrou (Prot) just uploaded another nice package to MELPA. It’s a simple little app that displays a font in an Emacs buffer but for those who are on an eternal quest for the perfect font it’s perfect.

The app displays a (configurable) bit of text—think “The quick brown fox…”—and an (again configurable) set of characters underneath. Currently, the app works only with locally installed fonts but Prot is planning to upgrade it to be able to display and install any font.

Prot describes it as a work in progress but it’s already useful and will probably become more so as Prot refines it. It’s not a big thing but it’s another nice example of how Emacs is—or can be made to be—a complete editing environment.

I’ve written about Peter Prevos and his Emacs Writing Studio several times [1, 2, 3, 4 ]. It’s a series of articles on using Emacs for long form writing. Now, happily, Prevos has announced that the project—or at least the first version of it—is finished and available as a book from several e-bookstores. The source files are also available from his GitHub respository.

This is, as I’ve written, a great resource with lots of useful information. But don’t take my word for it. Protesilaos Stavrou also has a few words to say about it. He has, in fact, contributed those words as a forward to the book.

Those of you who have been around for a while know that I’m very interested in stories about people who use Emacs for non-technical purposes such as prose writing. Those who share that interest will find Prevos’ book a handy resource for using Emacs in their own projects.

I’ve read a lot of Prevos’ articles but never read them through as a book. I’m looking forward to reading the complete work.

There are some people who prefer to run Emacs in terminal mode. I have no problem with that but I do think that GUI Emacs has so much more to offer that it’s usually the best choice. Sometimes there’s no choice.

The need to use terminal mode often comes up when developers have to work on remote systems rather than their local machine. The usual advice is to use Tramp, which often works well and solves the problem but sometimes—especially with remote servers that are not on the local network—tramp can be too slow.

Wai Hon Law is in that situation. His employer does not allow source code on individual machines so he has do all his development on a remote server. Tramp didn’t work for him so he had to find another solution.

That solution involves a good terminal emulator and tmux. The two main problems are getting good colors for syntax highlighting and enabling the clipboard. These mostly depend on choosing the right terminal emulator but Law’s solution may not help too much because he’s using Chrome OS but there are doubtless terminal emulators suitable for your system.

The TL;DR is that you may have to experiment a bit to find the right emulator for your OS but once you do, you can look at Law’s post to get an idea of the other things you need.

I’m lucky that I’ve never been in this situation and could always just use Emacs in GUI mode but if you aren’t so lucky, take a look at Law’s post to see some possible ways forward.

Gene Goykhman over at Flaky Goodness has a nice hint on profiling garbage collection but the technique is more generally applicable. Goykhman wanted to know how much time he was spending in garbage collection while exporting his blog. It turns out there’s a really easy way to find that out.

The function benchmark-run will run its argument and report the total running time, the number of garbage collection calls, and the total time spent in garbage collection. That’s useful information to know for any function, even if all you’re interested in is the total running time.

Goykhman was concerned that garbage collection was taking up a significant amount of time in his export process so he arranged to inhibit it when he was exporting his blog. That worked out well for him but even if it’s not your problem, the benchmark-run function seems like a useful way of measuring the performance of your functions and perhaps adjusting things to improve performance.

Charles Choi has a very informative post on the Emacs upgrading policy a very informative post on the Emacs upgrading policy. The TL;DR is that by default Emacs’ package.el will not upgrade packages that are builtin. Org is an example of this. The package is builtin but the Org team issues updates much more frequently than Emacs itself is upgraded. There’s a variable, package-install-upgrade-built-in, that can override this behavior and force package.el to upgrade packages whether or not they’re builtin.

When I read his post, I thought, “This is great. It’s the answer to why Org sometimes doesn’t upgrade correctly.” But then I realized that Org is upgraded by package.el even though package-install-upgrade-built-in is set to nil on my system.

So now I don’t know what’s going on. Org is certainly a builtin package but it doesn’t seem to be behaving in the manner described by Choi and the documentation. Choi’s use case involves transient, which he depends on for his Casual suite. He needed a later version but it was not upgraded for at least one of his users.

Perhaps the policy is restricted to the update of dependencies although the documentation does not reflect that. Fortunately, this is Emacs and all the source is available and hackable so it’s just a matter of digging into the code to see what’s going on. Perhaps I’ll do that in the near future but for now it’s enough to know that someone has thought about the issue and attempted a solution.

Updates
[2024-08-30 Fri 12:12]:

Philip Kaludercic explains what’s going on in this comment. What package-install-upgrade-built-in really does is interpret built-in as installed. Take a look at the comment for the full explanation.

[2024-09-02 Mon 18:16]:

Added link to Choi’s post.