Re: [PATCH] Fixing package-initialize, adding early init file

[Radon Rosborough]

> > > I haven't seen one place where the problem_s_ involved have been
> > > clearly articulated
> >
> > Unless by "problems involved" you meant more generally, for all the
> > different proposals? That is exactly what [2] was intended to cover;
> > could you clarify what exactly you would like articulated that hasn't
> > been already?
>
> I meant more explicitly--each of these use cases should be documented
> with examples.  While the manual in its current state does explain
> things, it can be better.

So you're complaining about the documentation? Fine, agreed. The
documentation can/should be improved. That is totally orthogonal to
this patch, though.

> > > this patch does not improve any of the places where user facing
> > > documentation was lacking in the first place
> >
> > Actually, I'd disagree. I think this patch improves the situation, not
> > by adding more documentation, but by reducing complexity and therefore
> > reducing the need for additional documentation.
> >
> > In particular, we no longer need to document the placement of
> > (package-initialize) in the init-file, as such placement is no longer
> > necessary.
>
> The only documentation I see is in NEWS and the manual, which is where
> the old documentation was.

So, again, you're complaining about the documentation? Again, fine,
agreed. But I don't think that's a reason to criticize this patch.
More documentation can be added in future patches; let's not confuse
matters by combining this change with general doc improvements.

> > > requires the user to not only understand the forms that must be in
> > > an init file
> >
> > Could you clarify what you mean by this? This patch has the effect
> > that users can put package configuration right into their init-file,
> > or use Custom to achieve the same, without having to know anything
> > about the package system.
>
> At the cost of users who customize package.el and don't need another
> init file.

Right, so we benefit the 100% (people who customize packages) at the
cost of the 0.1% (people who need to customize package.el in the early
init-file). A win-win, no?

And it's still not clear to me why you think having an early init-file
is such a big problem.

> package archives

If I understand correctly, package-archives need not be set before
package-initialize is called. Thus the number of people who would need
to use the early init-file is quite small indeed.

> > and this patch *maintains* that behavior.
>
> which is why it gets a -1 from me.

The behavior I was referring to was "the built-in package manager
works out of the box". Are you really saying that having the built-in
package manager work out of the box is a bad thing?

> An improvement from package--ensure-init-file is great, but that's still
> more breakage than prior to package--ensure-init-file.

Prior to package--ensure-init-file, when people pasted Lisp code from
their packages' READMEs into their init-file, they would get errors.
This was a very common problem for people new to Emacs, see [1]. That
affects everyone, so it should be considered "major breakage".

> Emacs itself doesn't work OOTB for most people.

I think we all agree that this is a bad thing. Shouldn't we be trying
to remedy this problem?

> That it's customizable in Elisp is a feature.

Yeah, but having sane defaults gets more and more important the more
powerful your tool gets.

[1]: https://lists.gnu.org/archive/html/emacs-devel/2015-03/msg01016.html