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

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Radon Rosborough
Hello all,

Attached is a preliminary patch for fixing "the package-initialize
problem" (see [1] [2] [3]) by adding an early init file. Feedback
welcome. In particular,

- do we want to try to factor out some common logic in loading the
  early init file versus the regular init file?
- have I broken anything in moving the check for an invalid username
  earlier in startup.el? what about moving package-initialize earlier?
- should `early-init-file' be defined in C?
- did I miss any documentation fixes?
- have I broken any style guidelines for the repository?

Additional question: if we moved forward with this patch, would it
make it into Emacs 26.1?

Best,
Radon Rosborough

[1]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html
[2]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00433.html
[3]: https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html

0001-Add-early-init-file-stop-package-initialize-insertio.patch (32K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Stefan Monnier
> Attached is a preliminary patch for fixing "the package-initialize
> problem" (see [1] [2] [3]) by adding an early init file. Feedback
> welcome. In particular,

Thanks, comments below.

>  ;;;###autoload
>  (defun package-initialize (&optional no-activate)
[...]
> +  (setq package-enable-at-startup nil)

BTW, in a subsequent patch we could rename this to package-initialized,
so the name reflects what the variable contains rather than what it's
used for.

> +  DEFVAR_LISP ("early-init-file", Vearly_init_file,
> +               doc: /* File name, including directory, of user's early init file.
> +If the file loaded had extension `.elc', and the corresponding source file
> +exists, this variable contains the name of source file, suitable for use
> +by functions like `custom-save-all' which edit the init file.
> +While Emacs loads and evaluates the init file, value is the real name
> +of the file, regardless of whether or not it has the `.elc' extension.  */);
> +  Vearly_init_file = Qnil;

This is not used from C code, so make it a plain old defvar in startup.el.

I haven't yet looked at the startup.el part, sorry.


        Stefan


Reply | Threaded
Open this post in threaded view
|

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

Radon Rosborough
> BTW, in a subsequent patch we could rename this to
> package-initialized, so the name reflects what the variable contains
> rather than what it's used for.

I don't think that's a good idea, since the most common usage of this
variable will be

    (setq package-initialized nil)

in the early init file, and that doesn't make much sense from a
readability perspective (are we asserting that package.el wasn't
initialized?).

> This is not used from C code, so make it a plain old defvar in
> startup.el.

Done. New patch attached.


0001-Add-early-init-file-stop-package-initialize-insertio.patch (32K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

John Wiegley
>>>>> "RR" == Radon Rosborough <[hidden email]> writes:

RR> Done. New patch attached.

This seems like a lot of changes that add new complications to the startup of
Emacs. Since I don't have time just now to review those 150 messages, may I
please ask for an executive summary to motivate this change?

--
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Reply | Threaded
Open this post in threaded view
|

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

Stefan Monnier
In reply to this post by Radon Rosborough
>> BTW, in a subsequent patch we could rename this to
>> package-initialized, so the name reflects what the variable contains
>> rather than what it's used for.
> I don't think that's a good idea, since the most common usage of this
> variable will be
>     (setq package-initialized nil)
> in the early init file, and that doesn't make much sense from a
> readability perspective (are we asserting that package.el wasn't
> initialized?).

Why would there be (setq package-initialized nil) in the early init file?
I could imagine there being

    (setq package-initialized t)

OTOH, to inhibit subsequent initialization of package.el.


        Stefan

Reply | Threaded
Open this post in threaded view
|

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

Radon Rosborough
In reply to this post by John Wiegley
> This seems like a lot of changes that add new complications to the
> startup of Emacs. Since I don't have time just now to review those
> 150 messages, may I please ask for an executive summary to motivate
> this change?

You could read [1] for an explanation of what the problem is, and [2]
for a list of the different ways people have proposed to solve it. But
I will summarize again:

* Currently, Emacs modifies the init-file to add (package-initialize)
  to it when Emacs starts. This has many disadvantages [1] which I'm
  not going to rehash here.
* There are many proposals [2] on how to make package.el work out of
  the box without requiring Emacs to modify the init-file. These all
  have practical disadvantages, except for the proposal to add an
  early init file, which solves the package.el problem with
  essentially no disadvantages, and furthermore solves several other
  problems at the same time (for example, people having no way to
  disable the menu bar before it is initialized the first time).

You can disagree with the above two points, but they were the outcome
of the aforementioned 150 emails, and everybody seems to agree that
this is the best approach. The only difficulty is actually making the
relevant changes to startup.el, which are honestly pretty small in the
grand scheme of things.

> new complications

The only new code is to load an additional init-file. It's definitely
a new complication, but I don't think it's that bad. The other changes
to startup.el are to add a new variable, and move the
(package-initialize) call and the check for an invalid user name to a
bit earlier. Sure, we need to test it thoroughly, but it's certainly
not *complicated*.

[1]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html
[2]: https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html

Reply | Threaded
Open this post in threaded view
|

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

Radon Rosborough
In reply to this post by Stefan Monnier
> Why would there be (setq package-initialized nil) in the early init file?
> I could imagine there being
>
>     (setq package-initialized t)
>
> OTOH, to inhibit subsequent initialization of package.el.

Whoops, that was indeed what I meant to say. But I still argue that
the readability is hurt, because (setq package-initialized t) is
basically a lie: you're saying that package.el was initialized
already, when in fact the purpose is quite possibly to ensure that
package.el is *never* initialized.

Reply | Threaded
Open this post in threaded view
|

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

Mark Oteiza
In reply to this post by Radon Rosborough

Radon Rosborough <[hidden email]> writes:

>> This seems like a lot of changes that add new complications to the
>> startup of Emacs. Since I don't have time just now to review those
>> 150 messages, may I please ask for an executive summary to motivate
>> this change?
>
> You could read [1] for an explanation of what the problem is, and [2]
> for a list of the different ways people have proposed to solve it. But
> I will summarize again:
>
> * Currently, Emacs modifies the init-file to add (package-initialize)
>   to it when Emacs starts. This has many disadvantages [1] which I'm
>   not going to rehash here.
> * There are many proposals [2] on how to make package.el work out of
>   the box without requiring Emacs to modify the init-file. These all
>   have practical disadvantages, except for the proposal to add an
>   early init file, which solves the package.el problem

I haven't seen one place where the problem_s_ involved have
been clearly articulated, and still this patch does not improve any of
the places where user facing documentation was lacking in the first
place, and still requires the user to not only understand the forms that
must be in an init file, but now there is one more init file for the
user to manage.

The whole discussion and push for a "solution" is predicated on users
who can't be bothered to do things correctly _not_ having to do any
configuration.  This patch does not improve things in this regard, and
frankly I don't see that predicate as a good one for devising a
solution. At least it explains how we ended up with
package--ensure-init-file.

> with
>   essentially no disadvantages, and furthermore solves several other
>   problems at the same time (for example, people having no way to
>   disable the menu bar before it is initialized the first time).
>
> You can disagree with the above two points, but they were the outcome
> of the aforementioned 150 emails, and everybody seems to agree that
> this is the best approach. The only difficulty is actually making the
> relevant changes to startup.el, which are honestly pretty small in the
> grand scheme of things.

I suppose it's time I pipe up and indicate I vehemently oppose this
change.  AIUI it still breaks existing config of package-archives,
package-load-list, etc, which is something the incumbent solution also
breaks.  The only proposal I can support at this time is reverting the
incumbent solution, yet none from the maintainership is willing to
entertain the idea.

>> new complications
>
> The only new code is to load an additional init-file. It's definitely
> a new complication, but I don't think it's that bad.

I think adding another init file is unacceptable.

Reply | Threaded
Open this post in threaded view
|

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

As for the problems with the current situation, check out [1] and also
the section for Proposal A in [2]. But again, I'll re-summarize:

* Emacs modifies the init-file automatically, without asking the user.
* If the user has set any variables related to package.el in their
  init-file, then Emacs will modify the init-file to do the wrong
  thing!

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?

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

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

If on the other hand "forms" is referring to 'setq' forms that
customize the package system itself, then indeed, users must know to
put them into a different init-file. However, I'd argue that this
isn't much worse than the current situation, where users must know to
put them *before* (package-initialize), and they must also know that
Emacs will put (package-initialize) in the wrong place with regard to
these customizations.

> The whole discussion and push for a "solution" is predicated on
> users who can't be bothered to do things correctly _not_ having to
> do any configuration. This patch does not improve things in this
> regard

Correct. The current behavior is that things work out of the box, and
this patch *maintains* that behavior. Since things already work out of
the box, I don't see how you expect this patch to somehow improve that
particular aspect any further.

What this patch accomplishes is eliminating the problems inherent in
automatic modification of the init-file, *without* losing the goal of
the package system working out of the box.

> The whole discussion and push for a "solution" is predicated on
> users who can't be bothered to do things correctly _not_ having to
> do any configuration [...] and frankly I don't see that predicate as
> a good one for devising a solution.

The goal is that when someone uses M-x package-install to install a
package, and then they paste some Lisp code from the project's README
into their init-file, then it works as expected. I think this is
desirable behavior, and I think most everyone else thinks this is
desirable behavior as well. That's why the current solution was put in
in the first place, because people really wanted that use case to
"just work". This patch achieves that same goal in a better way.

> AIUI it still breaks existing config of package-archives,
> package-load-list, etc, which is something the incumbent solution
> also breaks.

Correct, but here is the important point: it will only do so *once*,
when people upgrade to Emacs 26. As opposed to the current solution,
which breaks existing config every time (package-initialize) is
inserted, which may happen many times for a given user. So this patch
is a definite improvement.

> The only proposal I can support at this time is reverting the
> incumbent solution, yet none from the maintainership is willing to
> entertain the idea.

That's because it would result in the built-in package manager not
working out of the box, which would be embarrassing from a UX
perspective. That's the whole *point* of having a built-in package
manager: that it works right away without additional setup.

> I think adding another init file is unacceptable.

Why? (Especially given that being able to run code before the first
graphical frame is initialized would be super useful for lots of
reasons, entirely separate from the package system.)

[1]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html
[2]: https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html

Reply | Threaded
Open this post in threaded view
|

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

Mark Oteiza
On 25/09/17 at 10:16pm, Radon Rosborough wrote:
> > 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.

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

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

> If on the other hand "forms" is referring to 'setq' forms that
> customize the package system itself, then indeed, users must know to
> put them into a different init-file. However, I'd argue that this
> isn't much worse than the current situation, where users must know to
> put them *before* (package-initialize)

The current situation should never have happened.

> > The whole discussion and push for a "solution" is predicated on
> > users who can't be bothered to do things correctly _not_ having to
> > do any configuration. This patch does not improve things in this
> > regard
>
> Correct. The current behavior is that things work out of the box

Except for users who who don't need garbage dumped into their init file
and for users who change their package archives or the list of activated
packages in their init.el without the need of a package-initialize form
because they read the docs.

Apparently changing those custom variables is an edge case.
https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00209.html

> and
> this patch *maintains* that behavior.

which is why it gets a -1 from me.

> > AIUI it still breaks existing config of package-archives,
> > package-load-list, etc, which is something the incumbent solution
> > also breaks.
>
> Correct, but here is the important point: it will only do so *once*,
> when people upgrade to Emacs 26. As opposed to the current solution,
> which breaks existing config every time (package-initialize) is
> inserted, which may happen many times for a given user. So this patch
> is a definite improvement.

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

> > The only proposal I can support at this time is reverting the
> > incumbent solution, yet none from the maintainership is willing to
> > entertain the idea.
>
> That's because it would result in the built-in package manager not
> working out of the box, which would be embarrassing from a UX
> perspective. That's the whole *point* of having a built-in package
> manager: that it works right away without additional setup.

Emacs itself doesn't work OOTB for most people.  That it's customizable
in Elisp is a feature.


Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Mark Oteiza
> Date: Mon, 25 Sep 2017 19:15:03 -0400
> From: Mark Oteiza <[hidden email]>
> Cc: [hidden email], Stefan Monnier <[hidden email]>,
> [hidden email]
>
> On 25/09/17 at 10:16pm, Radon Rosborough wrote:
> > > 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.

It definitely can, but that's a separate issue, I think.  And we
cannot finalize the documentation before we finalize the code.

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

Do those users have a "fire escape"?  If they don't, I agree we should
provide one.  Otherwise, I expect such users to be knowledgeable
enough to work around these changes with minimal hassle.

Reply | Threaded
Open this post in threaded view
|

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

Radon Rosborough
In reply to this post by Radon Rosborough
I noticed that discussion seems to have died off on the
package-initialize patch. Is there anything I can do to
help it along?

> Attached is a preliminary patch for fixing "the package-initialize
> problem" (see [1] [2] [3]) by adding an early init file. Feedback
> welcome. In particular,
>
> - do we want to try to factor out some common logic in loading the
>   early init file versus the regular init file?
> - have I broken anything in moving the check for an invalid username
>   earlier in startup.el? what about moving package-initialize earlier?
> - should `early-init-file' be defined in C?
> - did I miss any documentation fixes?
> - have I broken any style guidelines for the repository?
>
> Additional question: if we moved forward with this patch, would it
> make it into Emacs 26.1?
>
> Best,
> Radon Rosborough
>
> [1]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html
> [2]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00433.html
> [3]: https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html

Reply | Threaded
Open this post in threaded view
|

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

Robert Weiner-2
In reply to this post by Radon Rosborough
On Mon, Sep 18, 2017 at 5:57 PM, Radon Rosborough <[hidden email]> wrote:
Hello all,

Attached is a preliminary patch for fixing "the package-initialize
problem" (see [1] [2] [3]) by adding an early init file.

​My thoughts are:

1. For most Emacs users who do not program in Elisp, there should be only a single init file that they would personalize, generally as they find snippets of code they can cut and paste for their use.​

2. For Elispers, another optional init file for more fine-grained control would be okay, though not ideal.

But this means whatever problem exists with package-initialize, it should be solved without requiring the use of a 2nd init file.

Bob


Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Robert Weiner <[hidden email]>
> Date: Tue, 10 Oct 2017 12:52:32 -0400
> Cc: emacs-devel <[hidden email]>
>
> 1. For most Emacs users who do not program in Elisp, there should be only a single init file that they would
> personalize, generally as they find snippets of code they can cut and paste for their use.​
>
> 2. For Elispers, another optional init file for more fine-grained control would be okay, though not ideal.

I think the proposed solution satisfies these requirements.  The 2nd
init file is only needed if you want to tweak package initialization
by putting Lisp code into that 2nd file.

> But this means whatever problem exists with package-initialize, it should be solved without requiring the use
> of a 2nd init file.

I don't understand how you reach this conclusion.  The problems we are
trying to solve exists only for those whom you call "Lispers", so
another init file is only needed in that case.  What am I missing?

Reply | Threaded
Open this post in threaded view
|

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

Radon Rosborough
In reply to this post by Robert Weiner-2
> 1. For most Emacs users who do not program in Elisp, there should be
>    only a single init file that they would personalize, generally as
>    they find snippets of code they can cut and paste for their use.

The entire reason these solutions are being proposed is because we
want to avoid the situation where people cut and paste snippets into
their init file, and they fail to work, which is what used to happen.
See [1].

And, as Eli already pointed out, for most Emacs users there *is* only
a single init file. It's only if you want to do advanced programming
that you need to use the second one, which need not exist at all.

> it should be solved without requiring the use of a 2nd init file.

Many, many possible solutions have already been discussed and
dismissed; see [2]. It's nice to hope for a better one, but I don't
think this should be considered a blocker unless someone actually
comes up with a better solution.

Best,
Radon

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

Reply | Threaded
Open this post in threaded view
|

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

Robert Weiner-2
On Tue, Oct 10, 2017 at 3:03 PM, Radon Rosborough <[hidden email]> wrote:

And, as Eli already pointed out, for most Emacs users there *is* only
a single init file. It's only if you want to do advanced programming
that you need to use the second one, which need not exist at all.

​That sounds fine.  When I mentioned 'package-initialize', I meant that users of packages who would call that in their init files should not need to have a second init file just to use packages and have them load properly.

Bob

Reply | Threaded
Open this post in threaded view
|

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

Radon Rosborough
> When I mentioned 'package-initialize', I meant that users of
> packages who would call that in their init files should not need to
> have a second init file just to use packages and have them load
> properly.

Indeed, you need only have a second init file if you would like to
customize `package-load-list', `package-enable-at-startup',
`package-user-dir', or other such low-level variables. (In particular,
`package-archives' can be set in the regular init file.)

In fact, with this patch, you don't even need to have any
package-related code at all in your init-file: not even
`package-initialize'. Packages can be installed, and they will "just
work", including if customizations are them are blindly pasted into
the regular init file.

Reply | Threaded
Open this post in threaded view
|

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

John Wiegley-6
>>>>> "RR" == Radon Rosborough <[hidden email]> writes:

RR> In fact, with this patch, you don't even need to have any
RR> package-related code at all in your init-file: not even
RR> `package-initialize'. Packages can be installed, and they will "just
RR> work", including if customizations are them are blindly pasted into
RR> the regular init file.

And if I never use packages, I'll never have this second file, right?  Because
right now, every once in a while, I find (package-initialize) getting inserted
into my init.el, even though I never once have used packages. Still haven't
figured out what's doing that.

--
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Reply | Threaded
Open this post in threaded view
|

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

Radon Rosborough
> And if I never use packages, I'll never have this second file,
> right?

Correct.

> Because right now, every once in a while, I find
> (package-initialize) getting inserted into my init.el, even though I
> never once have used packages.

Literally the entire point of this patch is to stop that from
happening without sacrificing any existing functionality.

12