About early-init right use.

About early-init right use.

[Ergus]

Hi guys,

Maybe this is a dumb question, but I am trying to update my setup to use
the newer early-init file. I made similar questions some days ago, but
it is still not clear to me (and I don't find a explicit documentation
about this yet).

What's the main advantage for the new early-init file and what are the
variables or portion of the configuration that should (or you recommend)
to moved there?

Because actually the only examples I find around are only single lines
with:

(setq-default package-enable-at-startup nil)

But I suppose that there should be many other recommended settings that
must go there and that could improve the startup.

I have read that one functionality for this file is to disable toolbars
and other things before they are loaded, but I have tried that and some
of them didn't work for me.

Thanks in advance,
Ergus

Re: About early-init right use.

[tomas]

[-- Attachment #1: Type: text/plain, Size: 2534 bytes --]

On Tue, Apr 02, 2019 at 01:54:36AM +0200, Ergus wrote:
> Hi guys,
> 
> Maybe this is a dumb question, but I am trying to update my setup to use
> the newer early-init file. I made similar questions some days ago, but
> it is still not clear to me (and I don't find a explicit documentation
> about this yet).
> 
> What's the main advantage for the new early-init file and what are the
> variables or portion of the configuration that should (or you recommend)
> to moved there?

Here's a quote from the 27.0.50 manual (Node "Customization > Init File >
Early Init File"):

    49.4.6 The Early Init File
    --------------------------
    
    Most customizations for Emacs should be put in the normal init
    file, ‘.emacs’ or ‘~/.emacs.d/init.el’.  However, it is sometimes
    desirable to have customizations that take effect during Emacs
    startup earlier than the normal init file is processed.  Such
    customizations can be put in the early init file,
    ‘~/.emacs.d/early-init.el’.  This file is loaded before the
    package system and GUI is initialized, so in it you can customize
    variables that affect frame appearance as well as the package
    initialization process, such as ‘package-enable-at-startup’,
    ‘package-load-list’, and ‘package-user-dir’.  Note that variables
    like ‘package-archives’ which only affect the installation of new
    packages, and not the process of making already-installed packages
    available, may be customized in the regular init file.
    *NotPackage Installation::.
    
       We do not recommend that you move into ‘early-init.el’
    customizations that can be left in the normal init files.  That is
    because the early init file is read before the GUI is initialized,
    so customizations related to GUI features will not work reliably
    in ‘early-init.el’.  By contrast, the normal init files are read
    after the GUI is initialized.  If you must have customizations in
    the early init file that rely on GUI features, make them run off
    hooks provided by the Emacs startup, such as ‘window-setup-hook’
    or ‘tty-setup-hook’.  *Note Hooks::.
    
       For more information on the early init file, *note (elisp)Init
    File::.

(Sorry: I'm too stupid to find an online version of a 27-ish manual.
There /must/ be such a thing, I'm sure).

Paraphrasing it, I'd say: "don't touch early-init.el unless you know
what you're doing" ;-)

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

RE: About early-init right use.

[Drew Adams]

> from the 27.0.50 manual (Node "Customization > Init File >
> Early Init File"):
> 
>     This file is loaded before the
>     package system and GUI is initialized, so in it you can customize
>     variables that affect frame appearance as well as the package
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     initialization process...
> 
>     the early init file is read before the GUI is initialized,
>     so customizations related to GUI features will not work reliably
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     in ‘early-init.el’.

Seems a bit contradictory wrt "variables that affect frame
appearance".  What variables are we talking about, if they
are not "related to GUI features"?

Re: About early-init right use.

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

On Tue, Apr 02, 2019 at 07:21:30AM -0700, Drew Adams wrote:
> > from the 27.0.50 manual (Node "Customization > Init File >
> > Early Init File"):
> > 
> >     This file is loaded before the
> >     package system and GUI is initialized, so in it you can customize
> >     variables that affect frame appearance as well as the package
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >     initialization process...
> > 
> >     the early init file is read before the GUI is initialized,
> >     so customizations related to GUI features will not work reliably
>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >     in ‘early-init.el’.
> 
> Seems a bit contradictory wrt "variables that affect frame
> appearance".  What variables are we talking about, if they
> are not "related to GUI features"?

Hm. I read it differently: putting things in early-init.el gives you
the chance to do things /before/ GUI and frame-appearance things are
initialized. Thus it gives you the power to fix things, but also
to break things.

Put it another way: you almost never want to put anything into
early-init.el -- unless you have the hunch that you need to change
something before GUIs get initialized (e.g. to let them "see" a
different variable value).

Or more TL;DR you better know why you are in there ;-D

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: About early-init right use.

[Ergus]

I know the manual is pretty nice, but some good examples for the "things
to put before the GUIs get initialized" is not a bad idea.  

I mixed some things I found here and there and mixed everything to
optimize the startup time (as an experiment)

```
(defconst my/start-time (current-time))

(defvar file-name-handler-alist-old file-name-handler-alist)

(setq file-name-handler-alist nil
      message-log-max 16384
      gc-cons-threshold most-positive-fixnum   ;; Defer Garbage collection
      gc-cons-percentage 1.0)

(add-hook 'emacs-startup-hook
          `(lambda ()
             (setq file-name-handler-alist file-name-handler-alist-old
                   gc-cons-threshold 800000
                   gc-cons-percentage 0.1)
			 (garbage-collect)
			 (message "Load time %.06f"
					  (float-time (time-since my/start-time)))) t)

(tool-bar-mode   -1)
(menu-bar-mode   -1)
(scroll-bar-mode -1)
(tooltip-mode    -1)			;; Tool tip in the echo
(flymake-mode    -1)

;;__________________________________________________________
;; For using Melpa and Elpa
(setq package-archives '(("gnu" . "https://elpa.gnu.org/packages/")
						 ("melpa" . "https://melpa.org/packages/")))

(setq package-quickstart t)

;;-------------------- Some tricks--------------------------
(provide 'early-init)
;;; early-init.el ends here

```

In fact this, mixed with the use-package :bind :commands and so on
reduced my loading time from ~2 to ~0.9 seconds.

But I think this is a little bit too much for the early init and some of
the options doesn't really produce any improvement, so they should go in
the init.el

But I wanted to have a "stronger" argument about what to put and what
not.



On Tue, Apr 02, 2019 at 05:42:22PM +0200, tomas@tuxteam.de wrote:
>On Tue, Apr 02, 2019 at 07:21:30AM -0700, Drew Adams wrote:
>> > from the 27.0.50 manual (Node "Customization > Init File >
>> > Early Init File"):
>> >
>> >     This file is loaded before the
>> >     package system and GUI is initialized, so in it you can customize
>> >     variables that affect frame appearance as well as the package
>>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >     initialization process...
>> >
>> >     the early init file is read before the GUI is initialized,
>> >     so customizations related to GUI features will not work reliably
>>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >     in ‘early-init.el’.
>>
>> Seems a bit contradictory wrt "variables that affect frame
>> appearance".  What variables are we talking about, if they
>> are not "related to GUI features"?
>
>Hm. I read it differently: putting things in early-init.el gives you
>the chance to do things /before/ GUI and frame-appearance things are
>initialized. Thus it gives you the power to fix things, but also
>to break things.
>
>Put it another way: you almost never want to put anything into
>early-init.el -- unless you have the hunch that you need to change
>something before GUIs get initialized (e.g. to let them "see" a
>different variable value).
>
>Or more TL;DR you better know why you are in there ;-D
>
>Cheers
>-- tomás

Re: About early-init right use.

[tomas]

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

On Tue, Apr 02, 2019 at 06:55:22PM +0200, Ergus wrote:
> I know the manual is pretty nice, but some good examples for the "things
> to put before the GUIs get initialized" is not a bad idea.

I think we agree that it can always be made better...

> I mixed some things I found here and there and mixed everything to
> optimize the startup time (as an experiment)

Interesting, but a bit... daunting as an example, I think :-)

Cheers & thanks for sharing
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: About early-init right use.

[Stefan Monnier]

> (add-hook 'emacs-startup-hook
>           `(lambda ()
>              (setq file-name-handler-alist file-name-handler-alist-old
>                    gc-cons-threshold 800000
>                    gc-cons-percentage 0.1)
>              (garbage-collect)
>              (message "Load time %.06f"
>                       (float-time (time-since my/start-time))))
>          t)

I recommend you don't quote your lambdas.

> (setq package-archives '(("gnu" . "https://elpa.gnu.org/packages/")
>                          ("melpa" . "https://melpa.org/packages/")))

You can set this in your `emacs.el` rather than early-init.el.

> (setq package-quickstart t)

You can set this in your `emacs.el` rather than early-init.el.
[ Controversially, the quickstart file is used at startup regardless of
  your package-quickstart setting.  ]


-- Stefan

Re: About early-init right use.

[Lele Gaifax]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> (setq package-archives '(("gnu" . "https://elpa.gnu.org/packages/")
>>                          ("melpa" . "https://melpa.org/packages/")))
>
> You can set this in your `emacs.el` rather than early-init.el.

Since a couple of months or so I moved the above setting to early-init.el,
after a suggestion (that unfortunately I cannot find the source anymore) to
workaround a problem with the M-x list-packages: customizing the
package-archives in the init.el as I used to, the listing shows almost all
packages marked as "new". 

I never got deep enough to understand the issue, but doing it in early-init.el
apparently fixes it.

Any further advice?

Thank you,
ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

Re: About early-init right use.

[Stefan Monnier]

> I never got deep enough to understand the issue, but doing it in
> early-init.el apparently fixes it.
> Any further advice?

AFAIK this was a transient problem that is now fixed.
If not, please report it as a bug.


        Stefan

Re: About early-init right use.

[Lele Gaifax]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I never got deep enough to understand the issue, but doing it in
>> early-init.el apparently fixes it.
>> Any further advice?
>
> AFAIK this was a transient problem that is now fixed.

Great.

> If not, please report it as a bug.

... two things to test tomorrow :-)

Thank you,
ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

Re: About early-init right use.

[Lele Gaifax]

Lele Gaifax <lele@metapensiero.it> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> I never got deep enough to understand the issue, but doing it in
>>> early-init.el apparently fixes it.
>>> Any further advice?
>>
>> AFAIK this was a transient problem that is now fixed.
>
> Great.

Looks like that's the case indeed: I uncommented the setting of
package-archives in my init.el, removed the early-init.el, and the listing
appears correct.

Thank you,
ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

Re: About early-init right use.

[Stefan Monnier]

> Seems a bit contradictory wrt "variables that affect frame
> appearance".  What variables are we talking about, if they
> are not "related to GUI features"?

If you can improve the wording it would help.  Indeed "related" is not
precise enough.

Since the GUI is initialized after loading the early-init.el, you can't
(yet) *ask* Emacs about the GUI (e.g. `window-system` will give you the
wrong info, frame sizes won't be right either, ...), but you can *tell*
Emacs about GUI-related settings like `(setq default-frame-alist ...)`.

You also can't use your installed packages from early-init.el because
they haven't been activated yet (tho you can manually activate them by
calling `package-activate-all`, of course).


        Stefan

RE: About early-init right use.

[Drew Adams]

> > Seems a bit contradictory wrt "variables that affect frame
> > appearance".  What variables are we talking about, if they
> > are not "related to GUI features"?
> 
> If you can improve the wording it would help.  Indeed "related" is not
> precise enough.
> 
> Since the GUI is initialized after loading the early-init.el, you can't
> (yet) *ask* Emacs about the GUI (e.g. `window-system` will give you the
> wrong info, frame sizes won't be right either, ...), but you can *tell*
> Emacs about GUI-related settings like `(setq default-frame-alist ...)`.
> 
> You also can't use your installed packages from early-init.el because
> they haven't been activated yet (tho you can manually activate them by
> calling `package-activate-all`, of course).

Maybe say that.  If there is a good reason why you
would define some "variables that affect frame
appearance" in the early file then maybe provide
that.

It's not because one _can_ define variables there
that one should do so, in general.  But if there
are particular cases where it might be _better_
to do it in the early file then maybe mention them.

In general, it needs to be made clear why you might
better put something in the early file (and perhaps
give some examples), and state the general guideline
that otherwise you should put everything in the
"late" file.