Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advanced techniques for reducing Emacs startup time

blog.d46.us

Post reply on HN
Print view View original

11–20 of 83 posts

Re: Advanced techniques for reducing Emacs startup time

#11

Post by timlod »

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!

Re: Advanced techniques for reducing Emacs startup time

#13

Post by jonpalmisc »

I’d like to see something like this but for speeding up Emacs at runtime. I have a 0.25s startup time with packages but my Emacs struggles when using lsp-mode or eglot in large C++ projects. I’ve been using Sublime Text lately but would like to get back to Emacs.

Re: Advanced techniques for reducing Emacs startup time

#14

Post by mickeyp »

vegai_ wrote: post #12

Here's mine: https://wiki.archlinux.org/title/emacs#As_a_systemd_unit and aliases ec='emacsclient -nc' e='emacsclient -c' I still use neovim because sometimes it's neater that the file opens up in the same terminal where I am in.

You can instruct Emacs (with or without emacsclient) to open in a terminal with:

   emacsclient -nw
That way, you'll connect to your Emacs server but using a terminal Emacs (even if your main instance is GUI Emacs)

Re: Advanced techniques for reducing Emacs startup time

#15

Post by faho »

timlod wrote: post #11

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 tr…

I 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.

Re: Advanced techniques for reducing Emacs startup time

#16

Post by vegai_ »

mickeyp wrote: post #14
vegai_ wrote: post #12

Here's mine: https://wiki.archlinux.org/title/emacs#As_a_systemd_unit and aliases ec='emacsclient -nc' e='emacsclient -c' I still use neovim because sometimes it's neater that the file opens up in the same terminal where I am in.

You can instruct Emacs (with or without emacsclient) to open in a terminal with: emacsclient -nw That way, you'll connect to your Emacs server but using a terminal Emacs (even if your main instance is GUI Emacs)

Oh, I wonder how I had missed that option. Thanks!

Re: Advanced techniques for reducing Emacs startup time

#18

Post by unhammer »

faho wrote: post #15
timlod wrote: post #11

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 tr…

I 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-insta…

I 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.

Re: Advanced techniques for reducing Emacs startup time

#19

Post by ilovecaching »

I gave up on Emacs and went back to Vim because of the slowness and the bugs I was encountering while using the Emacs GUI (granted a lot of them were from lsp-mode and other heavy packages). While digging for answers I was told not to use certain platforms, don't use the GUI, use the GUI, don't turn Emacs off etc. which felt like Stockholm syndrome to me. There's a lot of cargo culted config fragments like the ones you'll find in the article. Why does every user have to constantly reinvent the same config to work around all of the issues in Emacs? I don't know, but I wasn't going to stick around and find out. Vim with all of my plugins, which has the same features as my Emacs config, starts up instantly and I've yet to encounter a single bug. I really wanted to like Emacs, and I've chalked up my bad experience to less people putting dev time towards it rather than actual negligence towards the user experience. In the article the author talks about how he's gone bankrupt three times with his config, maybe that's a sign that the problem isn't the author. If Emacs is that fragile, then its extensibility is really a moot point.

Re: Advanced techniques for reducing Emacs startup time

#20

Post by hprotagonist »

faho wrote: post #9

Ideally use-package would simply be included in emacs, so you could rely on it. Apparently they are getting close: https://github.com/jwiegley/use-package/issues/282 Until then, I have this in my init.el to install it if necessary: ;; Install use-package because that installs everything else (unless (package-installed-p 'use-package) (package-refresh-contents) (package-install 'use-package)) (require 'use-package)

except that use-package, by itself, does not install anything.

  NOTE: use-package is not a package manager! Although use-package does have the useful capability to interface with package managers (see below), its primary purpose is for the configuration and loading of packages.
(I use straight, which interfaces nicely into use-package.)
Post reply on HN