3 ms·
I do what the author mentions as the common retort to their approach: starting an Emacs daemon (server) at boot, and opening Emacsclient when needed. In general
by timlod 4y ago
I do what the author mentions as the common retort to their approach: starting an Emacs daemon (server) at boot, and opening Emacsclient when needed. In general, I always have one frame open to do actual work on, but the client is still useful if I ever navigate with a file explorer or open things through the command line (all text extensions open in Emacs).
I'm not sure all the extra effort needed really does the trick - I don't think mine would start up 'fast enough' to beat running a daemon even if I deferred loading most of my config (which can lead to config issues at times).
That being said, I had a look at their dotfiles, and it seems really well organized. If such an effort makes you write a great config, it may be worth it regardless of whether you end up using the daemon or not!
- faho 4y agoI prefer having a clean instance so I can open up an emacs for the project I'm currently working on, as opposed to lugging all those other buffers around and leaving any changes intact. So I don't use a daemon. And these "advanced techniques" aren't really all that hard - 90% is just using use-package, which has a number of other advantages. It can be set up to install uninstalled packages, so you can do a self-installing init.el. In my case mine will download my other config files, install use-package and then install all packages I use. It also leads to better organization of your config, because you keep the packages self-contained instead of splattering random settings all over init.el.
- unhammer 4y agoI no longer let use-package install things. I use the same init on different computers, so sometimes I would have to wait for use-package to install things on startup and sometimes melpa would be down or some package would be a newer version and require new deps and use-package doesn't handle such situations. It's very little gain for a lot of hassle. Instead I just check all of emacs.d/elpa into the same git repo. That way I can also easily review changes or roll back to last working version.
- morelisp 4y agoI tried this for a while but got sick of dealing with byte compilation issues. Different versions of Emacs on different systems, occasional mtime skew especially if switching branches but sometimes I think just an unlucky clock tick.
- _pvxk 4y agogitignore the .elc's
- ParetoOptimal 4y agoI use use-package with nix but disable package.el being able to install anything. This way I get fast startup and the download problem you mention doesn't happen. If nix isn't your thing, I used to do the same with straight.el by checking in .emacs.d/straight and disabling install by setting repos to nil.
- lvass 4y ago>lugging all those other buffers around project(ile)-switch-to-buffer is your friend.