RFD: Rationale for not leveraging use-package

[jonathanunderwood]

This is a fantastic learning resource, and in general the design principles seem very sound - I love how you've explained those principles, and they're clearly visible through the code.

After reading the code and the docs, I had one lingering question: given the emphasis on Emacs built-in functionality (e.g. Eglot, soon to be part of core Emacs distribution) I wondered why you took the decision not to leverage use-package, especially given that it will soon be part of the Emacs core distribution. I ask, not because I am challenging the decision, but just because it would be educational to understand, and a nice addition to the docs.

[jeffbowman]

Thank you for your question.

use-package is a good tool to use for configuring Emacs. At the time we created Crafted Emacs we chose to be as transparent as possible with the code we write so others can learn from it. use-package as a macro does some fairly nice things under the hood, but obfuscates a lot of what is going on in order to provide a consistent interface to writing your own configuration. You can, if you choose, learn a lot from use-package by simply running it through macroexpand and reviewing the result. To learn more, you can peruse the source code for use-package.

For us, at the time, we felt that was too much "magic" going on and could be difficult to understand. The code written in Crafted Emacs is intended to be simple to read, focused on "correctness" in the sense of using the appropriate APIs, and readability. We do have one macro which is a thin wrapper around the usage of either striaght.el or package.el so installing packages is consistent without the need for a lot of conditional logic to handle the different package managers.

With Emacs 29 including use-package, we may choose to revisit the decision to opt-out of its usage. That discussion has not yet been had, and there are a number of things we may need to tweak to bring the project up-to-speed with Emacs 29. I'm anticipating the number of bug reports to increase after that release.

Hope this helps answer your question!

[jonathanunderwood]

It does, thank you for taking the time to respond.

[ajxn]

I had a look at the suggested change in the documentation, and I do think that there are no reason to add that to README.org. Has anyone had a look at the Pull Request?

[jonathanunderwood]

I had a look at the suggested change in the documentation, and I do think that there are no reason to add that to README.org. Has anyone had a look at the Pull Request?

That's fine - I offered it up to be a "good citizen" since @jeffbowman took the time with a thoughtful reply. But if it's just adding cruft to the README, then please feel free to close the PR unmerged.

[jeffbowman]

Yes, I looked at the PR. Thanks for the suggestion. I haven't merged it as I have been thinking about it from the perspective of how to handle the answer as generically as possible and not necessarily specifically about just use-package.

That said there are fairly substantial changes coming to Crafted Emacs in the near future which may make this answer moot.

[jeffbowman]

Closing post v2 release, I'll leave this pinned for a while, but may remove the pin at some point in the future.