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
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.el to pre-compute an autoload
file so that the activation of packages can be done much faster, resulting in a
faster startup1. And indeed it does, resulting in more or less the same 0.4
seconds that I was getting with
One thing to be aware of is that, as the documention of
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
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