Drew,
Some of this is a little redundant because it's already been said by
other people. Sorry about that.
> > 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.
You are wrong. Libraries that are shipped with Emacs are put in the
load path and have their autoloads evaluated, and this is exactly what
the package manager does to activate a third-party package -- nothing
more, nothing less.
In particular, the package manager *certainly* does not actually load
any features; that would be unacceptable.
> 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.
What? How would package code get added to the load path, then? Would
users do that manually? That would defeat the entire purpose of
package.el, namely to add package code to the load path for you.
Honestly, I think the package.el-config-file proposal gets the closest
to your desired situation, by making it so that `package-initialize'
need not be called from your code, and you do not have to think about
where to place it.
> No one has shown that most users want wrt automatic pkg-mgt
> enabling, afaik.
That's because most of us consider it common knowledge. I challenge
you to either (1) find somebody else here who thinks that this
statement is false, or (2) suggest a practical way we could test its
validity.
> > 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.
>
> [...]
>
> But all of that is, I think, irrelevant, or at least I don't see the
> relation.
Because most users want to use a package manager, it should be enabled
by default. That is my argument, and that is why what I said is
relevant. It is irrelevant whether the default enable/disable state of
other Emacs features has been decided correctly.
> I can't judge whether you are right about how many other problems
> your proposal will solve.
Eli, at least, has proposed exactly the same as what I'm suggesting,
and had this to say about the package.el-specific config file:
the problem we are solving with this file is a much larger one,
and affects many more users [than the problem of dealing with a
new config file].
> > 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.
Customize never modified the init-file automatically, without asking.
> How dire is the situation wrt the pkg system, realistically?
It's impossible to answer this objectively. But the current situation
reflects a horrible design flaw, and I think it's important that core
Emacs code reflects good design. I think everyone else here agrees
with me there, although we may all have different opinions on what
that good design should be.
> 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).
Because we could make it so that `package-initialize' doesn't need to
be called at all, and then such documentation would be superfluous.
Two birds with one stone.
> But it seems to work well enough that zillions of users make good
> use of it everyday.
Same for Microsoft Windows XP, which currently runs on about 140
million computers worldwide. The size of the userbase is irrelevant to
design questions.
> Do you really think that most pkg users who have problems have the
> more complex kinds of problems for which your proposal is intended?
Why do you say my proposal is intended to solve "complex kinds of
problems"? It is intended to solve the problem of people forgetting to
put `package-initialize' in their init-files, which as you mentioned
is the #1 most common problem people have with package.el.
Sure, the current situation also solves that problem. But it goes
about it in the wrong way, and introduces a number of silly negative
side-effects.
> I don't see zillions of questions about it.
>
> I do see some, which often boil down to this answer: call
> `package-initialize'.
Well, we could solve all of those questions in one fell swoop with the
package.el-specific config file, by eliminating the need to call
`package-initialize'.
> 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.
Sorry, but I feel the same way as Mark (and I know for a fact that
there are a fair few other users who concur, but are too burnt out to
comment here; see the Reddit thread I linked). If I tried to write
documentation for package.el, it would go like:
In your init-file, you must call `package-initialize', which
shouldn't be necessary but is due to design flaws. As a hacky
workaround to fixing the underlying problem, Emacs will add this
function call to your init-file automatically if it is absent.
However, note that it usually does so incorrectly, and you will
have to fix it by hand.
> > 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.
Fine. But as I said, that discussion is orthogonal to this one. Better
documentation is not a substitute for good design, nor does the
converse hold.
> > 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?)
I've written more than 40 emails here in an attempt to improve the
usability. Because this effort is time-consuming, I'm focusing on one
and only one thing: improving the usability. Not improving the docs,
even though I also think the docs should be improved.