Re: Questions regarding use-package (Emacs)
The following is an excerpt from a recent exchange. It is reproduced with permission. The identity of my correspondent remains private.
I remember watching one of the earlier videos of yours where you mentioned you do not use use-package anymore. IIRC the reasoning was to utilise Emacs built-ins more and rely less on external code.
Just out of morbid curiosity, were there any other reasons? Since use-package is now part of the core, and you have matured even more as an Elisp developer, would you have any notes on improving use-package to make it more applicable for larger audience?
Another reason behind asking this is, I’ve been trying to get more into Elisp understanding and use-package, as it happens, was the project I picked to start with.
Any ideas/advice/suggestions welcome.
I will answer your question. Can I publish this on my website, so that I can reference it in the future if somebody else asks me? I want to include the quote directly above. I will keep your details a secret. Is that okay?
Starting with the point about prioritising built-in functionality: I
continue to do so, though I also account for a package’s overall
quality and fitness for purpose. If a third-party package appears to
me as better than its built-in alternative, I opt for it. Examples
include my modus-themes when I first designed them in response to my
dissatisfaction with available built-in options, but also my
preference for vertico over icomplete, ido, and even the
standard Completions’ buffer.
This is informed by my refined understanding of what it means for a
standalone package to be shipped with Emacs as opposed to being
available in some package archive: there is no technical difference
between the two. My modus-themes, for example, is a standalone
package. It is the same whether a user gets it directly from core
Emacs, some package archive, or clones it directly from the Git
source. The inclusion of a standalone package in Emacs does not, in
and of itself, somehow upgrade or alter it.
Exception to this are foundational packages that are meant to be used by other projects, such as for parsing data or creating new user interfaces (e.g. transient.el). Those benefit from inclusion in core Emacs, as they became a standard that the community can reference.
Couched in those terms, I think use-package does not change by its
mere addition to core Emacs: it is not a foundational package that
other projects need to depend on. So if I was not using it before, I
have no reason to use it now. Which brings me to the “why” that is.
I stopped using use-package because (i) I did not like how its
domain-specific language deviates from how the same things are done
without it and (ii) did not want to deal with inconsistencies in its
syntax.
The DSL is inconvenient for me. For example, the :custom entries
cannot be evaluated on a per-form basis the way they are with, say,
setq and now setopt. If I want to evaluate specific forms without
the whole package declaration, I must take the forms out of their
:custom context, rewrite them, and then do my work. Even if a
keyboard macro or query-replace makes the rewrite easier, it still
is something I have to do: it interferes with my flow. Same idea when
converting the value of a :hook to the add-hook syntax; :map to
define-key.
As for the inconsistencies I alluded to, I did not want to deal with
how the :hook keyword defaults (or defaulted?) to omit “-hook” from
hook symbols, while :map keeps the “-map” suffix in the
corresponding symbols. I know that there is/was a user option for
:hook, but that still breaks things for users who copy code that
includes the suffix but have not set that option accordingly—I had
to provide support for this incompatibility multiple times, to the
point where I realised it was not worth it.
Taking a step back, the extra features of use-package such as
:defer are not useful in my setup. I do not care about startup
times. Not one bit. I launch Emacs once per session. When I am
done, I close it and switch off the computer. The way I do it is to
launch Emacs, go fetch a drink, and then get back where I expect
everything to be available. So what if it takes 5 seconds or a
minute? I was away from the computer. With :defer I would have to
stop in the middle of my workflow to wait for the packages to become
available. All for a small improvement to emacs-init-time that I
was not benefiting from anyway, as I was still fetching my drink
during startup.
I ended up using use-package as the equivalent of:
(progn
;; do stuff
)
I know this is what use-package is reduced to once we remove all the
extras (:custom, :hook, :map, :defer, …), so this is exactly
what I did in my dotemacs. I did it my own way to prevent people from
having the false safety of copy-pasting code without thinking about
it. I want those who read my config to understand what they are
doing. It works for me and is highly opinionated, which is what the
Emacs spirit is all about.
I must stress that this is not an argument against use-package. I
am happy that it is added to core, as it is the de facto standard.
Lots of users will benefit from this change. It just so happens that
I am not among them.