Quick starting is a bendy road

After more than a year with straight as my package manager, recently I have decided to sit down and look closely at how I handle my Emacs packages.

For all the interesting design choices and splendid documentation straight offers, I have never used neither its version freezing capabilities nor the chances to edit the source code of a package to try possible fixes before sending patches upstream. Two reasons, mainly:

• I update my packages on a daily basis, accepting the risk of breakages in order to signal them to the maintainers and offer some help;
• when I want to send a patch, I have the source code of the package I am working on outside of my Emacs configuration to avoid leaving something messy around.

These are not issues with straight, of course. It all depends on what one needs from their package manager.

One of the major benefits that straight brought to my setup is a boost in startup speed. However, why don’t give package-quickstart a try? Setting package-quickstart to t instructs package.el to pre-compute an autoload file so that the activation of packages can be done much faster, resulting in a faster startup.¹ And indeed it does, resulting in more or less the same 0.4 seconds that I was getting with straight.

One thing to be aware of is that, as the documention of package-quickstart suggests, “the use of ‘package-quickstart-refresh’ every time the activation need to be changed, such as when ‘package-load-list’ is modified” is required. Hence, I added an :after-while advice to package-menu-execute (bound to x in Package Menu) to make sure package-quickstart-refresh is run after every upgrade.

Again, mine is not an argument against straight. It’s still a great package manager and a fantastic alternative to the built-in package.el. However, these days my Emacs interactions do not need the fine-grained control straight provides.