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

[Drew Adams <drew.adams@oracle.com>]

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

> It seems to me that use of package.el should be just like use of any

> other library. Users should explicitly opt in. But I understand that

> you've said that it has been decided to enable the package system by

> default for everyone, at the outset.

 

The rationale for this decision was that we want to treat package.el

as a core part of Emacs rather than as an extension. 

 

Lots of things are a core part of Emacs and not extensions, but we don't necessarily turn them on by default. `cua-mode' is a core part of Emacs, but it is off by default (good). `delete-selection-mode' is a core part of Emacs, but is off by default (bad).

 

We're not talking about whether package.el is core or external (at least I'm not). And we're not talking about loading package.el by default. We're talking about activating the package system by default.

 

If the rationale for the decision was only that you want to treat package.el as a core part of Emacs rather than as an extension then that's a bad rationale. You don't need to turn something on just because it is a core part of Emacs.

 

If you want to debate that, then fine (I might join you), but let's take it as

granted for a moment. If package.el is a core part of Emacs, then we

expect all of its features to work by default. 

 

All of `cua-mode' works by default, but it is not turned on by default.

 

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?

 

That's why it's enabled by default.

 

So that's a second rationale. That one is even worse than the "because it's core" rationale. Nebulous.

 

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

 

Note that I'm not really complaining about this decision, even though

I don't like package.el and never use it. It seems reasonable to me

for the built-in package manager to act like this, even if I don't use

said package manager.

 

I still haven't seen an argument why we shouldn't have users opt in to turn on use of the package system. Other than the simple observation that some users have gotten confused about how to appropriately turn it on.

 

Sounds like the decision amounts to throwing up one's hands and exclaiming that since some users don't know how to properly turn it on we should just go ahead and turn it on at the outset for all users. Copout?

 

> It doesn't matter, IMO, if 99% of the users want to opt in; it

> should still be opt-in.

 

It really depends on whether you view package.el as a core part of

Emacs or not. 

 

I don't think so. See above. What does "core part" have to do with it? (And what does "work similarly" have to do with it?)

 

After all, the menu and tool bars are turned on by default; VC is turned on by default (even though lots of people turn it off and use Magit); why shouldn't the package manager be turned on by default?

 

The question is not why shouldn't it. The question is why should it. No good answer, so far.

 

`cua-mode' is not turned on by default. Yet its behavior is used by 90% of users outside of Emacs. `delete-selection-mode' is not turned on by default (but it should be). `transient-mark-mode' was not turned on by default for decades (it finally was, thank goodness, but only after a lot of time and debate). And so on. 

 

I think it's fine for stuff to be turned on by default as long as it's

easy to turn it off again and swap in something else:

 

     (menu-bar-mode -1)

     (tool-bar-mode -1)

     (setq vc-handled-backends nil)

     (setq package-enable-at-startup nil)

 

I'll certainly do that. Along with (electric-indent-mode -1).

 

(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.)

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