Re: Summary and next steps for (package-initialize)

[Radon Rosborough <radon.neon@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4492 bytes --]

> > And we also expect libraries installed using package.el to work
> > similarly to libraries that are shipped with Emacs.
>
> Dunno what that means. Work similarly how? How could they work
> differently?

Libraries that are shipped with Emacs are made available automatically
without anything needing to be put in the init-file. And this happens
during startup, before the init-file is loaded.

OTOH, if package.el needs to be set up manually, as you propose, then
libraries that are installed using package.el would not be made
available automatically unless (package-initialize) was in the user's
init-file, and they would not be made available until part-way through
the loading of the init-file.

Now you may prefer the latter, but you can't argue that it's more
consistent behavior.

> Why does enabling it by default follow from wanting libraries
> installed by it to "work similarly" to libraries shipped with Emacs?

Is this clear now?

> I still haven't seen an argument why we shouldn't have users opt in
> to turn on use of the package system.

It's because most people want to use the package system (you admitted
this yourself). As you observed, we have a large assortment of tidbits
in Emacs core, and whether they are enabled by default depends on
whether most users want them enabled by default.

> `cua-mode' is not turned on by default. Yet its behavior is used by
> 90% of users outside of Emacs.

Irrelevant. Most people don't use it *inside* of Emacs, so it's
disabled by default.

> `delete-selection-mode' is not turned on by default (but it should
> be).

I'm not saying the decisions about defaults have been made flawlessly.
But it's pretty hard to argue that it's more common to want the
package manager disabled than it is to want it enabled. Defaults are
supposed to eliminate work for the user; what good are they if they
don't align with what most people want?

> > (setq package-enable-at-startup nil)
>
> I'll certainly do that. Along with (electric-indent-mode -1).

As I'm sure you're aware, you're very much in the minority in both of
these things. So you probably shouldn't be surprised that the defaults
are not suitable for you. I'm aware that I'm in the minority in using
a package manager other than package.el, so I have no qualms with
having to override the defaults.

> (But apparently I'll need to put the `package-enable-at-startup'
> setting in another, "secondary" init file, as an exception. Not a
> big deal. Kinda clunky though.)

Agreed, it's clunky. But also agreed, it's not a big deal: and
considering how many other problems we solve by doing it this way, I
think it's a pretty good tradeoff to make.

> Why isn't the package-system doc improvement started, as the first
> thing to do?

Because the current situation (Emacs modifies the user's init-file) is
a catastrophe, and fixing that is an ASAP priority. Also, people (e.g.
Mark Oteiza) are reluctant to document package.el when the current
behavior is clearly broken.

> Seems like that would be a good thing for those who are familiar
> with the package mgr and are strong proponents of it to work on.

I agree but the docs improvements are orthogonal to fixing the code.
Indeed, improving the documentation would be our top priority if we
were going to disable package.el by default, which is what you want.
But we're not going to do that (based on what I've heard from everyone
else), so the docs are not necessarily our top priority.

> > I'd like us to give more visibility to Emacs packages, because I
> > commonly run into people who use package in Atom or Visual Studio
> > Code, but not in Emacs (and that's not because Emacs provides the
> > corresponding features without an extra packages)
>
> That is *not* a great reason to enable something by default.

Actually, it's a great reason. You know how GitHub is kicking GNU's
tail in marketing Atom? Well, "built-in package manager" is literally
on the front page of their website, right next to "use productively
without ever touching a config file". I'd say this is an indication
that people care very much indeed about their text editor coming with
a package manager that works right out of the box.

> Emacs users know both.

No, they don't. At least not the sort of users we want to attract, who
don't know anything about Emacs. Yes, all the people on emacs-devel
know this stuff, but emacs-devel is about 1% of Emacs users, and about
0.01% of the Emacs users we could have if Emacs worked better out of
the box.

[-- Attachment #2: Type: text/html, Size: 5951 bytes --]