emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Calling (package-initialize) sooner during initialization


From: Artur Malabarba
Subject: Re: Calling (package-initialize) sooner during initialization
Date: Mon, 27 Apr 2015 16:15:30 +0100

> Why ?
> If the default is using always the custom-file, this file could be
> loaded by default before the init file.
> And IMO it should be the default, writing custom setting at end of init
> file is the first thing one want to prevent when writing its emacs init
> file.

I see. So you're talking about loading custom-file automatically,
before loading the init file.
You can't just do that, because that will cause failure for some init
files that currently work fine.

Some users out there may have some code in his init file that needs to
be run before the custom variables are loaded.

2015-04-27 15:46 GMT+01:00 Thierry Volpiatto <address@hidden>:
>
> Stefan Monnier <address@hidden> writes:
>
>>> Why don't you write to the custom-file (and make the use of custom-file
>>> the default instead of writing custom settings in .emacs by default) ?
>>
>> When should the custom-file be loaded?  Before .emacs is too early.
>
> Why?
>
> What is the difference with:
>
> - (load custom-file) + (load user-init-file)
> - loading init file with (load custom-file) on top of it.

None. Stefan's point was that we can't force the user to load his
custom file at the top of his init file (nor can we load it before the
init file), because there are situations where the user needs to run
some code before the custom variables are loaded.

Besides, other options have been suggested around here, none of which
break the system for users with special custom-file needs, so I'd
suggest you look into them. One is about adding the directories under
emacs.d/elpa to the load-path before loading the init file (without
calling full-on package-initialize). The other is about dividing
startup between pre-initialize and post-initialize, it is more
heavyweight but it has the advantage of also fixing some other issues
with custom.el.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]