Decrease Emacs' launch time when using straight.el

I have been on a quest to decrease my Emacs startup time and found something that I haven't seen mentioned on any of the blogs I came across on the topic. I think it is fairly well known that if you use straight.el, deactivating package.el in your early-init.el will speed up your starting time. What I only just found out is that on launch, straight does a lot of checks to see if any of the packages installed have been altered. This process can be changed by modifying the `straight-check-for-modifications` variable. I don't edit any of my straight packages by hand, so I have this set to `nil`, before bootstrapping straight. This brought my startup time from ~2 seconds to ~0.5 seconds, for loading over 200 packages. Maybe there are some reasons why one shouldn't do this that I don't know, but it seems to be a nice way to save some time! For more information, see this section of straight's read-me: https://github.com/raxod502/straight.el#customizing-when-packages-are-built Hopefully this is of help to someone!

run emacs --daemon automatically at startup. Put (server-start) in your init file. Run emacsclient to launch emacs (from icon or OB menu item). Enjoy emacs loading in the blink of an eye. This is what we all should be doing. It is no longer a worry of slow emacs startup times. Load it in the background at startup, as above, and have it there to call it instantly when you want it. [Emacs Client](https://www.emacswiki.org/emacs/EmacsClient)

[deleted]

Uwu theme loads for me every time. 'smex 'Yasnippet, 'Spaceline, 'auto-complete, 'org-roam and 'ob-plantuml all load and run perfectly for me too. I use an external LaTeX from inside emacs and that's fine too. Perhaps I'm lucky. Dashboard looks interesting but I don't run it or All-the-icons for that matter so I can't comment or help, ..sorry. It sounds like it can be a bit buggy from what you're saying and certainly worth knowing.. thanks TT.

[deleted]

On 1.: My cursor is black unless I run the load-theme myself at startup. No clue why. Super annoying. Good to know others have similar issues.

[deleted]

You can disable package.el? EDIT: I'm assuming it's `(setq package-enable-at-startup nil)`

That is what I meant!

I use the [Emacs server](http://www.gnu.org/software/emacs/manual/html_node/emacs/Emacs-Server.html) so it starts instantly (except with a fresh login).

Thanks for clarifying! I was hoping to speed my install up a bit but I already have that.

> Maybe there are some reasons why one shouldn't do this that I don't know, but it seems to be a nice way to save some time! What happens if you `M-x straight-pull-all` to update your packages and then restart Emacs? Are you using the versions you've just pulled or the versions from the last time they were built?

To my knowledge, manually deactivating package.el in your init shouldn't be necessary. `straight-enable-package-integration` is `t` by default, which enables the [`straight-package-neutering-mode`](https://github.com/raxod502/straight.el/blob/af5437f2afd00936c883124d6d3098721c2d306c/straight.el#L6358) global mode when straight.el is loaded. `straight-package-neutering-mode` sets `package-enable-at-startup` to `nil` and further overrides both `#'package--ensure-init-file` and `#'package--save-selected-packages`

>Emacs Dashboard needing a hack-around I have this in my init, does it qualify as a hack-around? ``` (when (daemonp) (setq initial-buffer-choice (lambda () (if (< (length command-line-args) 2) (get-buffer dashboard-buffer-name))))) ``` It's also not really specific to emacs-dashboard, it's if you want to change the initial buffer with emacs daemon and also sometimes use the client with arguments to open files.

I put all the graphical stuff (theme, fonts, cursor...) on `focus-in-hook` to be called after the first frame is created. The function deletes itself from the hook to make sure it's only called once. That fixed most problems I had with themes. Basically something like that: ``` (defun tv/first-graphical-frame-hook-function () (remove-hook 'focus-in-hook #'tv/first-graphical-frame-hook-function) (provide 'tv/gui)) (add-hook 'focus-in-hook #'tv/first-graphical-frame-hook-function) ``` and all the stuff I want to defer are wrapped in `(with-eval-after-load 'tv/gui ...)` forms.

The readme of straight.el says this > Users of Emacs versions >= 27 will want to add: > > (setq package-enable-at-startup nil) > > to their early init-file to prevent package.el loading packages prior to their init-file loading.

You’ve got a bug somewhere in your setup. If you’re seeing it with daemon/client, it’s either oddly specific (as in, you somehow have a weird setting/code chunk that only happens when run via emacsclient) or you’re probably also seeing it any time you create a new frame (C-x 5 2, etc.). I say this because —daemon/client doesn’t load themes faster; it loads the theme when emacs starts (I.e. when you run emacs —daemon), and then it keeps using that running emacs. To get different theme behavior for different frames, code somewhere needs to go to extra effort to either load a different theme, or disable (unload) the theme. Whenever I’ve seen this in the wild, it’s either because of oddness that got perpetuated by an .emacs.desktop file or custom settings. Usually these are the result or partial leftover results of attempts to partially delay/defer startup code, or by attempts to use different themes on gui/tty, and usually you want to remove these vestiges anyway. If you launch “emacs —daemon”, then launch “emacsclient -c &” a couple times and see the theme in the first client frame but not the second, or in neither client frame, you can probably track this down. Try M-x customize-theme in the first frame that doesn’t load your theme, and see what custom thinks your theme setting should be. If this isn’t helpful, I’d personally suggest saving your custom settings somewhere as. A backup, then removing both the custom settings and any .emacs.desktop files entirely, then starting emacs again. You’ll probably have to set your theme manually once more (depends a bit on how you load it/them), but it should “stick” normally after that. FWIW, I’ve been using —daemon with various themes and all-the-icons (and —dired and —completions) for a long time now. The dashboard does need some special attention, because it’s really not obvious what to do when a new client frame starts up, but that attention was well supported by dashboard when I last tried it months ago. Hope that helps!

> Maybe there are some reasons why one shouldn’t do this that I don’t know, but it seems to be a nice way to save some time! The main reasons someone wouldn’t want to do this are the same sorts of reasons one wouldn’t want to disable automatic updates (or automatic checks for new updates) in their OS. In both cases, there are entirely reasonable situations where one would prefer to disable or defer the automatic checking, even while the default is reasonably left on.

I use emacs for everything, ofc I start a server and it only starts once. However, you have a good point, fast startup is always nice. You are missing a lot of straight.el if you don't modify packages, bc it empowers you to modify packages on the fly and it will work.

[deleted]

[deleted]

>For someone who expects to get their Emacs init loaded "as though it were fresh" only without having to wait, it's a hack around. With this (or even without, actually, maybe just giving a constant value to `initial-buffer-choice` would be enough for that), you can use `emacsclient -c` exactly as you would `emacs`. `emacsclient -c` gives you an empty frame, `emacsclient -c toto.txt` gives you a frame with the file toto.txt. It won't be "as though it were fresh", because it will have access to all the buffers opened in other clients, true. But that's not really a problem with the dashboard. So I still don't quite get what the problem is. (But I understand it if you don't want to waste time explaining a problem which you have solved already...)

[deleted]

Huh! Color me wrong I guess. That said maybe straight.el ought to start recommending bootstrapping in early-init rather than init so that isn't a problem.