[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs-29 acd462b0306: ; Improve the use-package manual

From: Philip Kaludercic
Subject: Re: emacs-29 acd462b0306: ; Improve the use-package manual
Date: Mon, 12 Dec 2022 20:06:54 +0000

John Wiegley <johnw@newartisans.com> writes:

>>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> It would also be nice to have user options like
>>> 'use-package-always-defer' enabled by default, but that will certainly
>>> break a number of configurations.
>> Those users can always (setq use-package-always-defer nil) to
>> recover the
>> old behavior.
> This should *not* be enabled by default.
> Basically, `:demand` and `:defer` are considered overrides, which
> basically short-circuit the intelligent in use-package that figures
> out when a deferred load would offer the most benefit. The `-always-`
> variables cause these overrides to be applied globally, but this is
> almost always a bad choice, since it means giving up one of the
> reasons why use-package exists in the first place: to figure out when
> things should be deferred, but not deferring them when it's unhelpful.

Most configurations I see online do use `use-package-always-defer' by
setting it to t, so it might be worth considering what use-package was
meant to do, and how it is being used.  It has been mentioned elsewhere
that use-package has a number of implicit assumptions that stem from
before the wide-spread usage of package.el and reliable autoloads.
Or at least that is how I make sense of keywords like :mode, :magit,
:interpreter, etc. which almost all package should set on their own (and
if they don't, they should.  It doesn't make sense to make every user
configure these things manually when it is well known that ".foo" is the
conventional file extension of foo-mode).

(It is by relying on the above assumptions that setup.el is under 800
lines long, without size ever having had been a priority (including
documentation and docstrings).)

I think it would be nice to see some space for use-package to evolve
along with the changing circumstances, requirements and expectations,
especially given how it is part of the core now, so the audience will
only grow.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]