Re: Adding use-package to core

[xenodasein]

Nov 13, 2022, 11:55 by relekarpayas@gmail.com:
> While Eli can speak for maintainers' perspective, here's my personal
> observations:
>
> It depends on package. Org-mode and modus-themes have only benefitted
> from being included in core and their development pace has kept up if
> not improved. Eglot progress may be harder to gauge, but at least in my
> personal observation, it hasn't reduced.

modus-themes is simply too good and deserves being a default theme IMO.
How has org-mode have benefited from being in core?  My personal
experience and observation from others is that it's users like too keep
it relatively up to date, and installing a more recent version while there
is also a built-in one is, confusing and error-prone.
eglot is a special case, it is more or less the primary function of a
code editor these days and should get even more attention until it isn't
the 'thing.'

> As for use-package,
> 1. The package has been stable and working without many complaints for a
> lot of people (myself included) for a long time. For all intents and
> purposes it can be declared "done" (a.k.a. frozen) and not many will
> complain.

It's GH page seems to have quite a bit of issues, and I had my frustration
with it because of it's poor handling of custom settings, I think there
is a lot of room for improvement and there is no need for urgency.

> 2. John has already mentioned that he is willing to hand-over maintains
> to whoever steps up to the job, and if they want to do it in core,
> that's how it will be. He has also mentioned that he doesn't have
> sufficient bandwidth to spend on future development of use-package hence
> the former statement.

Okay, who has taken up this task for the foreseeable future? It's GH
page says otherwise.  Plus, it's author having stopped working on it
is not a great argument either.

> 3. Considering the adoption of use-package in wider Emacs user base, I'd
> say it is already near impossible to make breaking changes. Moving to
> core only makes that process more formal with decade long deprecation
> policy.

There is always oversights when it comes to volunteer software, why risk
it when it worked perfectly thus far being an Elpa package?

> 4. If you need someone to complain about use-package not being in core,
> you can count this mail as first. When I started out with Emacs in 2020,
> use-package was already recommended way in half the packages I found,
> and installing it required adding MELPA. Depending on where you stand
> with technical and ethical grounds, this is already not ideal. Less
> elisp needed to be understood by newbies (even if one-line MELPA
> addition) the better.

IIUC it is in Elpa, so this problem is solved now?  If not, then keep it
in Elpa.  Having it in core is going to improve what exactly?  It is
kind of a flavor pack.

> 5. While as a developer I agree that more code means more maintenance
> burden, we are not here to reduce development burden. Only code that is
> maintenance free is one that is never written, after all. However, Emacs
> is there to serve the needs of users. IME declarative configuration that
> use-package provides is so clearly superior to current imperative
> manner that it is worth adding more code, especially if this new code is
> as battle tested as use-package is.

IMO declarative macros are a lot more opaque and comes with other
unnecessary hurdles, so let's not call these preferences superior.
I admit it is easier to copy paste declarative configs when one has
little experience with Emacs, but this is yet another band-aid by itself.

> 6. As for your last point, Emacs is not Python. One of the things I
> really really like about Emacs is, even if I never install a single
> package, the stock setup gives me a LOT of stuff built-in. While my
> personal Emacs is riced to the brim, at work I use plain Emacs with very
> very little customization (11 lines in init.el) and it does the job.
>
> Perhaps these points can change your point of opinion. Feel free to
> correct wherever necessary.

This is all the more confusing to me; the point of use-package is to
make the usage of packages you install from wherever easier.  So if
someone is installing packages anyway, then they first install
use-package if that is the route they want.  You say you are also
fine with using the source code editing facilities already existing
in Emacs, I agree that those should come out of box and have priority
(as long as the maintenance burden isn't too much for the maintainers.)
However, use-package is not that, it is all about installing things so
let it get installed if that is the preference someone takes.  Why force
it on everyone when there is no benefit?  Better to focus effort on
editing oriented, relatively un-opinionated stuff in the core used by
everyone as well as you (like simple.el, python-mode) instead.

> Thanks,
> Payas

Thanks