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

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

[-- Attachment #1: Type: text/plain, Size: 13049 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.

 

Yes, just by putting them in (the default value of) `load-path' - no? That's not all that the pkg mgr does, IIUC. If it were then I guess we wouldn't be having this discussion.

 

OTOH, if package.el needs to be set up manually, as you propose, 

 

I'm not aware that I proposed anything particular. I asked a few questions, and expressed some doubt, about (what I understand of) some proposals.

 

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.

 

The way things worked before is that a user put libraries in `load-path'. Which is what emacs -Q does, no?

 

That's a user putting something in a particular location. And then possibly loading it. Lots of Emacs "core" stuff is in the same boat: in `load-path', waiting passively to be loaded. Possibly autoloaded. But in any case it is the user who loads it, directly or indirectly. (Some core stuff is preloaded.)

 

The difference is that for a non-default library the user decides where to put it - the user might have customized `load-path'.

 

All of that still seems a fair distance from pkg-mgr behavior.

 

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

consistent behavior.

 

I said nothing about preferring anything about how to use `package-initialize'. My naive preference is not to have a`package-initialize' and so not to have to worry about where it is placed or when it is evaluated.

 

> 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?

 

Not at all. Libraries shipped with Emacs do not, so far, use the pkg mgr or anything like it, afaik. They instead "work similarly" to how users have long accessed libraries that are not shipped with Emacs: explicit load or autoload from `load-path' - no pkg mgr-like behavior.

 

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

 

Actually, I think I probably said that many users now use the package system. I don't recall saying anything about what most people want.

 

I haven't said that we should do away with the pkg system. I said I haven't seen a good argument why we shouldn't have users opt in, to turn it on.

 

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.

 

Again, I think you might be putting words in my mouth. I don't think that I said that the tidbits that we have chosen to enable by default were enabled because most users want them enabled by default. In fact, in the past I've argued that sometimes Emacs dev has decided to enable some tidbits that I doubt most users wanted enabled by default.

 

But all of that is, I think, irrelevant, or at least I don't see the relation.

 

> `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.

 

I don't think that's the reason it was not enabled. At least that's not my recollection of discussions about whether to enable CUA mode.

 

More like chicken vs egg. If Emacs had decided to enable it by default 20 years ago then perhaps most users would use it inside Emacs - dunno.

 

But again, it's not very relevant to this discussion, I think, whether most users use CUA or would use it. I didn't claim that most users want the pkg system enabled by default. Perhaps you did; I don't think I did. I have no good idea about what most Emacs users want in that regard.

 

(FWIW, I haven't seen a poll of the users yet, I think, on any question, even though RMS has requested multiple times that Emacs dev "poll the users" about this and that.)

 

> `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. 

 

Dunno why you say that, which I guess really means that you think it is easier to argue that it's more common for users to want it enabled. What evidence do you have for that? I never argued that most users want the pkg mgr disabled.

 

Defaults are supposed to eliminate work for the user; what good are they if they don't align with what most people want?

 

No one has shown that most users want wrt automatic pkg-mgt enabling, afaik.

 

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

 

I too have no qualms with overriding defaults.

 

And I already said that my contribution here is not related to my own use or preference wrt pkgs. I am not asking that Emacs set its default pkg-mgr behavior to suit my use - not at all, as I think I've made clear.

 

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

 

I can't judge whether you are right about how many other problems your proposal will solve. Maybe you are. But if the clamor of support for your proposal so far is any indication, it might not be so many.

 

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

 

Was it considered so before you proposed your proposal?

 

I too don't like the idea of Emacs modifying user init files. But we've lived with that for at least as long as we've had Customize - many, many years.

 

I advise against not using a `custom-file', but I wouldn't say that the current situation of Emacs writing to init files is "a catastrophe". That's a bit hyperbolic.

 

How dire is the situation wrt the pkg system, realistically? I see the occasional question here and there about packages not being enabled after "installing" them, with the inevitable answer being to just add `package-initalize' to your init file. I don't see such questions a lot, frankly, but I do see them.

 

I certainly do not see lots of questions about complicated situations where `package-initialize' was called at the wrong time etc. I'm sure that arises, but those questions are not the ones I see often. Maybe I don't hang out where all the complex use cases are reported as problems.

 

Again, don't get me wrong. I am not saying the pkg mgr needs no improvement.

 

I'm questioning whether a good dose of better doc etc. wouldn't go a long way, and wondering why there isn't a first emphasis on that: getting out the good word to those who are confused about the simple need to call `package-initialize' (somewhere, at least).

 

Take care of that confusion/misunderstanding and my guess is that you'll take care of most of the user questions about enabling pkgs. (There, I said it: "most". Just a guess, though.)

 

Also, people (e.g. Mark Oteiza) are reluctant to document package.el when the current behavior is clearly broken.

 

Too bad, truly.

 

But it seems to work well enough that zillions of users make good use of it everyday. As I say, I don't see zillions of questions about it.

 

I do see some, which often boil down to this answer: call `package-initialize'. And I also see lots of other questions, many of which are also pretty simple to answer - questions about quoting or variable behavior or whatever.

 

We have all kinds of users, and some have questions, some of which have simple answers. Do you not think that most user problems/confusion with the pkg system can be answered fairly simply? You talk about "most users". Do you really think that most pkg users who have problems have the more complex kinds of problems for which your proposal is intended?

 

I don't expect so, but I could be wrong. I think better doc would greatly help most pkg users. It's a shame that someone might take the point of view that because the pkg system has some problems they wouldn't want to bother to document it better. That smells a bit like a copout.

 

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

 

It could reasonably be an immediate priority whether or not the pkg system is disabled by default. It is the users of the pkg system who have the difficulties with it, mostly minor I expect. It's not the non-users like I who most need better doc for it.

 

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? 

 

Sorry, I'm not in such a race. Not one of my goals for Emacs. Never has been.

 

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.

 

(Do ours care enough to improve the docs and usability?)

 

Anyway, there the question was not about caring whether the editor comes with a working pkg mgr. It was about whether we especially need to give more visibility to the fact that Emacs has packages. Not the same thing.

 

> The use of packages by Emacs users has taken off very quickly and

> sees no sign of abating.  I see no argument that we need to turn

> on the package manager by default just to let users know that there

> is a package manager and there are packages.  Emacs users know both.

> YAGNI.  That's not where they need help with packages.

 

No, they don't [know both]. At least not the sort of users we want to attract, who don't know anything about Emacs. 

 

Emacs users do know both that there is a package manager and that there are packages, I think. Do you really doubt that?

 

You are changing the question in order to disagree, I think, by saying that non-users - but people you want to become users - do not know both things.

 

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.

 

Poll Emacs users to see if they know Emacs has 3rd-party packages. I see user questions, at all levels, all the time. From my vantage point Emacs users certainly are aware of packages.

 

(Oh, and my guess is that emacs-devel is much less than 1% of Emacs users - probably much less than .01%. Whatever the ratio, it will be interesting to see the expected 100-fold increase in the number of users from implementing your proposal. ;-))

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