Making My Emacs Start Faster(wmecole.com)
wmecole.com
Making My Emacs Start Faster
http://www.wmecole.com/2015/11/making-my-emacs-start-faster.html
46 コメント
Likewise. I start emacs --daemon from systemd, and have aliases for using emacsclient to open emacs in a new frame, in the current terminal, or in a new screen window.
If you have any details, links, hints about how to accomplish this (for instance, where does one find a proper "emacsclient.service" file?) please consider yourself emboldened
I use the system service ([email protected]) from [this blog post][0]. I used 'systemctl enable [email protected]' so that emacs is always started on boot.
I have a one-liner shell script called 'em' that just runs 'emacsclient -t $*' so that it can be set as $VISUAL and used by whatever command line tools use that.
[0]: http://blog.refu.co/?p=1296
I have a one-liner shell script called 'em' that just runs 'emacsclient -t $*' so that it can be set as $VISUAL and used by whatever command line tools use that.
[0]: http://blog.refu.co/?p=1296
I had a slightly different approach in that I made a script to launch Emacs server on-demand: https://github.com/qiushihe/dotpiles/blob/master/emacs/emacs...
Starting from systemd is a league beyond what I've done. But you might like this script:
#!/bin/sh
emacsclient -t $@ || (emacs --daemon && emacsclient -t $@)
(unless (server-running-p)
(server-start))
Or use
emacsclient -t --alternative-editor=""
I don't have a systemd example, but here's a GNU dmd service that I use which shows how to properly start/stop the daemon:
https://git.dthompson.us/dotfiles.git/blob/HEAD:/dotfiles/.d...
https://git.dthompson.us/dotfiles.git/blob/HEAD:/dotfiles/.d...
Me too. Well, once per reboot. Even under very good circumstances, Emacs' startup time is worse than mg or vi. And having it run in the background, keeping its state, open buffers, shell history, etc. is very convenient.
Since I moved to spacemacs, I've been doing this.
However, I am bummed by emacsclient's inability to open multiple files from the command line.
And apparently the total lack of a Tab-like experience on Emacs in general. I used to use "vim -p" SO MUCH.
However, I am bummed by emacsclient's inability to open multiple files from the command line.
And apparently the total lack of a Tab-like experience on Emacs in general. I used to use "vim -p" SO MUCH.
what's wrong with http://www.emacswiki.org/emacs/TabBarMode ?
Seems like that only really works for GUI emacs. I use command line. I tried enabling it and it doesn't seem to, y'know, work.
I've also tried evil-tabs, which doesn't work with spacemacs, at all. And eyebrowse doesn't actually use tabs (also it doesn't maintain working directory state when opening a new workspace, fun!)
I dunno, emacs is very much, "Here's a half-implemented solution that pays zero attention to ergonomics. Just... y'know, fix the rest of it so it doesn't totally suck."
And I just don't have the experience to do that yet. Which is why I'm using Spacemacs. Which more or less actually tries to do the ergonomics correctly.
edit: I'm also hoping Cunningham's Law works in my favor here.
I've also tried evil-tabs, which doesn't work with spacemacs, at all. And eyebrowse doesn't actually use tabs (also it doesn't maintain working directory state when opening a new workspace, fun!)
I dunno, emacs is very much, "Here's a half-implemented solution that pays zero attention to ergonomics. Just... y'know, fix the rest of it so it doesn't totally suck."
And I just don't have the experience to do that yet. Which is why I'm using Spacemacs. Which more or less actually tries to do the ergonomics correctly.
edit: I'm also hoping Cunningham's Law works in my favor here.
In the spirit of Cunningham's Law, you can open multiple files using emacsclient. Just list them after emacsclient (e.g. 'emacsclient file1.txt file2.txt'). This will open each file in its own buffer (roughly the equivalent to tabs).
Since I'm not very familiar with vim tabs, I'm curious what you get using using vim tabs that you don't get out of emacs buffers?
Since I'm not very familiar with vim tabs, I'm curious what you get using using vim tabs that you don't get out of emacs buffers?
> In the spirit of Cunningham's Law, you can open multiple files using emacsclient. Just list them after emacsclient (e.g. 'emacsclient file1.txt file2.txt'). This will open each file in its own buffer (roughly the equivalent to tabs).
emacs buffers are (almost exactly) equivalent to vim buffers. vim tabs don't really have an analogue in emacs, but imagine several layouts of (emacs) windows (each window showing a single buffer) you can switch between in a single frame.
emacs buffers are (almost exactly) equivalent to vim buffers. vim tabs don't really have an analogue in emacs, but imagine several layouts of (emacs) windows (each window showing a single buffer) you can switch between in a single frame.
That's actually how emacs frames work on the terminal. There's no built-in equivalent on GUI. You could use either multiple GUI frames and a tiling window manager, or there are several packages on melpa for switching between window configurations.
The buffer list is shared across the entire emacs daemon. So if I have many files already open in different client sessions and start running buffer next commands, I'm cycling through a very long list.
Because you never ever start vim in a daemon mode, opening with -p creates a local list of files that you can cycle amongst. Additionally, the top line tells you which file you have open and which files are next and previous in the list of files you cycle through.
I've always just found it rather nice since I tend to jump around between the same handful of files while I'm working and hitting gt two or three times is often faster and more mindless than remembering the keystrokes to invoke helm-projectile-find-file and also the name of the file I want to switch to.
Because you never ever start vim in a daemon mode, opening with -p creates a local list of files that you can cycle amongst. Additionally, the top line tells you which file you have open and which files are next and previous in the list of files you cycle through.
I've always just found it rather nice since I tend to jump around between the same handful of files while I'm working and hitting gt two or three times is often faster and more mindless than remembering the keystrokes to invoke helm-projectile-find-file and also the name of the file I want to switch to.
That makes sense. I actually never use daemon mode because I don't want to share buffers. If want a faster start up time but don't want to share buffers you may want to look at use-package[1] which will lazy load plugins. Also, if you want a easy way to cycle through buffers that also works in the terminal I recommend iflipb[2]. When you start cycling, it shows a list of buffers in the mini-buffer. Both of those are available as packages in Melpa.
[1] - https://github.com/jwiegley/use-package [2] - https://github.com/jrosdahl/iflipb
[1] - https://github.com/jwiegley/use-package [2] - https://github.com/jrosdahl/iflipb
iflipb sounds like it more or less scratches the thing that makes me itchy even if it's not quite my old itch scratcher. Thanks!
Tab bar mode conflicts with a bunch of other modes. So a lot of times you will switch to a buffer and and the tabs will disappear. It also doesn't support 'most recent' tab ordering.
This. This emacsclient startup time is excellent. The complaint that each launched client shares the same buffers is hardly sufficient to justify the effort of lazy loading to achieve only mediocre performance.
I used to do this:
Unfortunately, since I've done it last, it seems that this feature has been 'fixed' with emacs now printing that it can only be dumped once. Never had a problem with multiple dumping before.
emacs --batch --eval '(dump-emacs "em" "/usr/local/bin/emacs")'
Unfortunately, since I've done it last, it seems that this feature has been 'fixed' with emacs now printing that it can only be dumped once. Never had a problem with multiple dumping before.
Moving to Emacs from Visual Studio means that I am amazed at how quickly it starts up even without any optimization.
Spacemacs solves this by lazy loading every package possible:
https://github.com/syl20bnr/spacemacs/blob/master/doc/DOCUME...
Spacemacs still starts up really slowly compared to vim and roughly equivalent plugins delivering similar features.
No, vim does not have anything that comes close to the killer feature (and only good feature) of Emacs: lisp.
I switched back to Vim from Spacemacs, because many of the features that I like about Vim seem more "solid." In Emacs, the environment can vary widely depending on your major mode, and several times I would end up in states that I did not know how to rectify without a full Emacs restart (to be fair these breakages were with evil-mode).
Like another poster said, there are so many things in Emacs that are half-baked and/or don't play well with other popular extensions. It's really annoying. I wanted to like Emacs, but I'm finding a better experience with Vim.
Edit: As an example of breakages with evil-mode, sometimes evil-mode would end up in a state where pressing 'd' once in normal mode would delete the whole line (which is supposed to be bound to 'dd') and I was unable to access any other combinations with 'd' as a result (e.g. 'd$' to delete to the end of line). It was annoying and happened fairly often, but was not reproducible (as in 'on demand') for me. IIRC, this spanned all buffers and I just had to restart Emacs to fix it.
Like another poster said, there are so many things in Emacs that are half-baked and/or don't play well with other popular extensions. It's really annoying. I wanted to like Emacs, but I'm finding a better experience with Vim.
Edit: As an example of breakages with evil-mode, sometimes evil-mode would end up in a state where pressing 'd' once in normal mode would delete the whole line (which is supposed to be bound to 'dd') and I was unable to access any other combinations with 'd' as a result (e.g. 'd$' to delete to the end of line). It was annoying and happened fairly often, but was not reproducible (as in 'on demand') for me. IIRC, this spanned all buffers and I just had to restart Emacs to fix it.
My thoughts exactly.
Coming from Vim I really wanted to like the idea of some fully async editor with Vim ease of navigation and Emacs power packages (org mode, async repl like iPython, etc) so I found the idea of Spacemacs awesome.
But in practice it's just too broken, after almost 2 days where I fully dedicated my time to do something as simple as showing line numbers in a consistent way, showing the Git gutter and showing the syntax checker marks in the gutter and being unable to solve the issue, I just gave up.
Mind you, this is just a small thing that should work right away (and does work right away in Vim), but seems impossible in Emacs because the packages just don't play nicely with each other. Worst, asking for help in Stackoverflow amounts to nothing, seems like the Emacs/Spacemacs just has their config and they don't want to touch it afraid to break it. The open bugs in Github for many of the troubles in Space are just mostly closed without an answer (really, for instance getting the theme colors to actually work in a terminal in OSX is a nightmare and nobody cares about it and the devs just close the bugs without solution).
Still, I'm still thinking about giving one last effort of just ditching Spacemacs and try to config Emacs from origin with evil mode and build from there, let's see.
BRIGHT SIDE: The philosophy being Spacemacs is really nice tough. I've been changing my Vim config to use a consistent approach to the <LEADER> keybindings and it's really productive and intuitive.
I just which there was some package that allowed to see the available keybindings in a small window at the bottom in Vim like you do in Spacemacs. That would be absolutely great.
Coming from Vim I really wanted to like the idea of some fully async editor with Vim ease of navigation and Emacs power packages (org mode, async repl like iPython, etc) so I found the idea of Spacemacs awesome.
But in practice it's just too broken, after almost 2 days where I fully dedicated my time to do something as simple as showing line numbers in a consistent way, showing the Git gutter and showing the syntax checker marks in the gutter and being unable to solve the issue, I just gave up.
Mind you, this is just a small thing that should work right away (and does work right away in Vim), but seems impossible in Emacs because the packages just don't play nicely with each other. Worst, asking for help in Stackoverflow amounts to nothing, seems like the Emacs/Spacemacs just has their config and they don't want to touch it afraid to break it. The open bugs in Github for many of the troubles in Space are just mostly closed without an answer (really, for instance getting the theme colors to actually work in a terminal in OSX is a nightmare and nobody cares about it and the devs just close the bugs without solution).
Still, I'm still thinking about giving one last effort of just ditching Spacemacs and try to config Emacs from origin with evil mode and build from there, let's see.
BRIGHT SIDE: The philosophy being Spacemacs is really nice tough. I've been changing my Vim config to use a consistent approach to the <LEADER> keybindings and it's really productive and intuitive.
I just which there was some package that allowed to see the available keybindings in a small window at the bottom in Vim like you do in Spacemacs. That would be absolutely great.
I agree with you. Being a former heavy vim user, now using Emacs, I miss vim every day. Spaceemacs wasn't for me, so I now have a modified Emacs Prelude. I was more effective with vim, but Emacs being a lisp is just hard to beat for me.
Here's to wishing for a better sort of programmers environment...
Here's to wishing for a better sort of programmers environment...
I too run emacs via systemd, and have emacsclient bound to a convenient shortcut in my window manager. It's just wonderful.
Emacs Reddit discussion "2 easy little known steps to speed up Emacs start up time"
https://www.reddit.com/r/emacs/comments/3kqt6e/2_easy_little...
https://www.reddit.com/r/emacs/comments/3kqt6e/2_easy_little...
You should give emacsclient a try. I start emacs once when my computer starts up, after that, emacs is instantaneous. I use projectile and neo-tree to customize my workflow, so I rarely need to leave my editor to switch projects, etc.
I also use spacemacs (GUI mostly), and would love to speed up the launch time when working from the terminal.
Spacemacs recommends[0] using `emacs-mac-port` via homebrew on OSX, but warns of the "strange"[1] emacs server behavior:
""" Note that the emacs-mac-port server behaves differently than the regular Emacs server. Details can be found on the emacs-mac-port README[1]. """
Has anyone taken the time to figure out a workaround to make this work in the traditional emacs manner?
[0] https://github.com/syl20bnr/spacemacs#os-x [1] https://github.com/railwaycat/emacs-mac-port/blob/master/REA...
Spacemacs recommends[0] using `emacs-mac-port` via homebrew on OSX, but warns of the "strange"[1] emacs server behavior:
""" Note that the emacs-mac-port server behaves differently than the regular Emacs server. Details can be found on the emacs-mac-port README[1]. """
Has anyone taken the time to figure out a workaround to make this work in the traditional emacs manner?
[0] https://github.com/syl20bnr/spacemacs#os-x [1] https://github.com/railwaycat/emacs-mac-port/blob/master/REA...
I have been using Emacs semi-casually since 1993, when I got into it because it had a really good [Lambda]MOO client. I have always hated Vi and like the C++ mode in Emacs, so when I'm on a shell-only or editing something that the IntelliJ suite doesn't do, I use Emacs.
It was slow to load back then on an early 90s HP/UX workstation. And it's slow to load now on a modern quad core i7 machine with 16 gigs of RAM and an SSD drive.
How this can be baffles me. I don't know what they're doing wrong, but it continues to grow and grow.
It was slow to load back then on an early 90s HP/UX workstation. And it's slow to load now on a modern quad core i7 machine with 16 gigs of RAM and an SSD drive.
How this can be baffles me. I don't know what they're doing wrong, but it continues to grow and grow.
How slow is "slow", for you? When my init was at its most bloated, it only took about ten seconds. I took out some things I wasn't using and got it down to similar timings to the article. (No SSD on this box, though.)
It actually loaded pretty fast for me on a less beefy system when I was using it. Even with SpaceMacs (which was a lot slower than my custom .emacs) loaded in 6 ~ 7 seconds.
I remember back in the day when Emacs stood for 'Eight Megabytes And Constantly Swapping' ... since then I've always got into the habit of keeping it running & never shutting down, startup was never speedy. It's nice to see that today's computers actually make a difference to emacs' startup times!
Just use 'emacs --daemon'!
Run emacs as a daemon and use emacsclient. Instant startup!
If whatever development system you are using is showing signs of being slow to start, I would say it is time to find a better, faster alternative?
I start emacs maybe once every 3 months if I have to reboot or something. Then it just runs constantly. The article is an interesting exercise but hardly important to optimize away 3 or 4 seconds a quarter.
Exactly, I always have an Emacs window (with tons of buffers, split screens) running.
I'd argue that startup time is very low on the list of things you want from your development system. Sure, quicker startup time is better, so improve it if you can, but you being productive in it once it's up is a lot more important, for example.
> I'd argue that startup time is very low on the list of things you want from your development system.
Depends on what part of your "development system" you're talking about. If your test suite takes a minute to load before it will even execute a single test, I'd argue that you might want to see what can be done about it.
Depends on what part of your "development system" you're talking about. If your test suite takes a minute to load before it will even execute a single test, I'd argue that you might want to see what can be done about it.
The shell is my development system. The editor is a small part of it. Starting it should be as fast as, say, opening a window in an IDE.
Launch emacs once ever and use emacsclient for the typical short-duration invoke/shutdown use cases.