load early-init.el if found

[emacs18]

Emacs 27 introduced early-init.el which is loaded earlier than init.el to setup package related things.

Both spacemacs and doom come with early-init.el in addition to init.el.

So loading of early-init.el I think is critical to use emacs 27 in general.

[emacs18]

I'm not sure that this patch is sufficient. It appears to me that spacemacs does not work quite right even with this patch applied. So please hold off on this patch. Further tweak may be needed.

[emacs18]

After more experimentation, the proposed change seems to be necessary change. Without this patch then early-init.el won't be executed. With the patch the code is executed. However I'm not sure whether it is evaluated at the right time. I think the basic design of chemacs may need to be revisited if we are to assure that early-init.el is handled properly, i.e., evaluated at the right time.

[emacs18]

I'm not sure that it is possible to load early-init.el file that comes with spacemacs and doom soon enough. https://github.com/syl20bnr/spacemacs/blob/develop/early-init.el shows that the only change that spacemacs need to make in ths file is to set package-enable-at-startup to nil. Also doom sets this to the same value. Hence my work around for now is to create ~/.emacs.d/early-init.el and add one line to set this variable. Note that ~/.emacs.d/early-init.el is loaded always unless emacs is started with -q or -Q option. So what will hapen for me now is that ~/.emacs.d/early-init.el will be loaded first whether I start spacemacs or doom. When I start spacemacs, then early-init.el within spacemacs directory will be read later on if my proposed patch above is applied. Ditto for doom, i.e., early-init.el that comes with doom will be loaded later.

While this is not an ideal situation, this seems to be workable solution for me now. If I need to support some other emacs configuation that requires far more complex setup within early-init.el, then I may need to come up with an alternate solution.

[plexus]

I don't think this approach will really help much. Loading early-init.el from Chemacs won't work, because by the time Chemacs kicks in (as installed in ~/.emacs) it is too late to do the kind of things that early-init.el is intended for.

I tried to google for a definitive explanation of early-init.el and how it interplays with ~/.emacs/~/.emacs.d/init.el, maybe someone can fill me in there. What happens when you have all three: ~/.emacs/~/.emacs.d/init.el/~/.emacs.d/early-init.el? Can early-init.el live anywhere besides ~/.emacs.d?

I think there are two or three potential solutions

• do nothing (status quo), i.e. users manage their own early-init.el, possibly checking for a --profile flag in there themselves if necessary. Since the most common use case seems to be to set package-enable-at-startup maybe that's something that people can set once even if it's shared between profiles
• change Chemacs so that it is installed as ~/.emacs.d/early-init.el. From there run the profile's early-init, then register a hook to load the regular init at the right time (we can't load it right away, we have to wait until things like the window system are initialized)
• split Chemacs into two parts, one that installs under ~/.emacs (or ~/.emacs.d/init.el) and one that installs as ~/.emacs.d/early-init.el, each handling their respective part of the startup process

To be honest I'm not hugely enthusiastic about any of these. The most appealing at this point I think is the "do nothing" approach, leaving it up to the users, maybe with a warning if a profile contains an early-init.el (which is then ignored).

The others mean we start mucking around in ~/.emacs.d, possibly getting in the way of people's default config. It's quite appealing right now that Chemacs can use ~/.emacs and that you can still have your own config in ~/.emacs.d that doesn't care about Chemacs. The cleanest solution there would be to say that Chemacs "claims" ~/emacs.d, and that your own configs should live somewhere else.

Solution 2 of installing Chemacs in ~/.emacs.d/early-init.el~ I think is the next best option, and I'd be happy to review a PR that does that. This could actually have some benefits, as it does allow us to set things like the user-emacs-directory and environment variables even earlier in the process, which can only help, but deferring loading the user config is important and needs to be figured out. Note that this would also have to update the install scripts, with appropriate warnings and messages to prevent mistakes.

[emacs18]

Doing nothing means that chemacs does not work reliably. I in fact started using #1 method you mention by creating ~/.emacs.d/early-init.el then adding one line to set package-enable-at-startup to nil. So for me, since I have the patch of this PR applied, my emacs loads ~/.emacs.d/early-init.el first, then early-init.el of spacemacs or doom.

I've had couple of subtle problems that no one else seems to run into which is resolved if I stop using chemacs and just make ~/.emacs.d point to spacemacs or doom. I would like to use chemacs to select type of config at run-time. However I'm not sure that is possible. I may write my own shell script to change ~/.emacs.d symlink each time emacs starts up! Of course I don't like this, but I am not aware of any reliable way to work around this early-init.el if I want to be able to select different startup files after emacs starts.

[emacs18]

I plan on experimenting with your #2 to use early-init.el for chemacs. I'll get back with some data later on.

[plexus]

Thanks, Richard :+1:

[plexus]

Something that comes to mind, it would be great if we could detect if we are being run from early-init.el or from .emacs, and in the latter case revert to the current behavior. This way people who don't need an early-init can continue to use .emacs as before.

[orialb]

Just wanted to chime in and say that I just now added a patch similar to this PR to my chemacs .emacs file, since the fact that early-init is not loaded is causing problems when using doom + emacs native-comp branch. I guess this is quite an edge case, but also it is possible that the people who use chemacs like to live on the edge :)

So I think it would be indeed great if chemacs supports early-init somehow, at the very least maybe it is worth adding a warning in the README about this.

[emacs18]

My first cut at implementing the idea we discussed above is at https://github.com/plexus/chemacs/pull/39

[plexus]

For folks following along at home, we are going ahead with the early-init support in a separate repo, https://github.com/plexus/chemacs2/pull/1