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

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

> > Personally, I don't think Emacs should be generating init files
> > in any case.  And certainly not generating an init file that
> > does something with the package system.  Emacs should continue
> > with the point of view that you start it, by default, with no
> > init file - no code at all.  Nada.
> 
> I agree wholeheartedly with everything you have said. However, a
> significant number of people on this list disagree,

Hm.  I haven't read this thread very carefully.  But I also
haven't gotten the impression that a significant number of
people here have argued for generating init files.  Not at all.
And I haven't gotten the impression that the default behavior
should be to start Emacs with no init file.  So I don't quite
follow you there.

> which is why I have made a middle-of-the-road proposal
> that is more likely to be accepted.

By "middle-of-the-road" are you perhaps referring to the fact
that you, like I, don't like Emacs messing with an existing
init file in order to try to tame package.el?  Is that what
you meant?  If not, I don't see anything one might call
"middle" about what (I understand of) your proposal.

> Do you agree that my proposal (only an init-file generated if one
> doesn't exist) is at least better than the current situation
> (hand-written init-file is modified programmatically by Emacs)?

Honestly, I'm not qualified to speak about solutions for
package.el problems.  I don't use the package system, myself.
So I can't say whether your proposal is better or is a
compromise of some sort.

I don't like the idea of Emacs generating an init file if
there is none OR of Emacs messing with an existing init file.

Sounds like a choice between being burned in the frying
pan or burned in the fire.  I don't see your proposal as a
"middle way", for users.  (It may be a middle way of sorts
for designers of the package system; dunno.)

> I'd like to fix the brokenness of the current situation before
> trying to move towards the best possible solution. If we accept
> this proposal, we could later think about things like removing
> (package-initialize) from the template init-file (although I
> doubt this will happen anytime soon, if ever, based on the
> feedback I got).

Doesn't sound like a great plan, to me.  But again, mine is
just one opinion, from someone who is not very familar with
the package system.

Naively, I'd suggest that package.el should do what custom.el
and bookmark.el and lots of other libraries do: Use a separate
Lisp file for persisting info the library needs - a file whose
name/location the user can set using an option.

If that would mean that a user might need to load that file
at an appropriate place in an init file, so be it.  The
package system might well require some understanding of it
before using it.

Customize is a bit like that: If you use a `custom-file' then
it is up to you to load it at an appropriate place in your init
file.  If you don't use a `custom-file' then you don't need to
worry about finding the most appropriate such place.  (But then
you need to worry about crosstalk between manual and automatic
edits - not worth it.)

(FWIW, I am also not in favor of Customize writing to your
init file.  I would prefer that we not only encourage use of
`custom-file' but we make it mandatory.  bookmark.el has it
right: require the use of a separate file.)

If it is difficult for users to find an appropriate place in
their init file to load whatever state/settings file package.el
might require, or to call `package-initialize' or whatever,
then perhaps the package system could be improved to help with
that somehow.

I say "naively" because I know next to nothing about package.el,
and I'm not trying to design the package system.  I have little
to contribute here, other than a wish, as one user, not to have
the package system mess with me or complicate things for users
generally.  I have faith that there is a way to do things sanely
for package.el, even if I don't have such a sane design to offer.