
Making My Emacs Start Faster - gk1
http://www.wmecole.com/2015/11/making-my-emacs-start-faster.html
======
sokoloff
I took the opposite extreme approach (and I think this is fairly common):

Launch emacs once ever and use emacsclient for the typical short-duration
invoke/shutdown use cases.

~~~
NoGravitas
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.

~~~
theophrastus
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

~~~
wging
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 $@)
    

You'll want something like

    
    
        (unless (server-running-p)
          (server-start))
    

in your init file.

~~~
tbirdz
Or use

    
    
        emacsclient -t --alternative-editor=""
    

and emacsclient will start the daemon if it hasn't already been started. You
can also set the ALTERNATIVE_EDITOR environment variable to "" to achieve the
same effect.

~~~
volent
After some investigation I found that the option and the env var are called
"alternate editor" and not "alternative editor".

~~~
tbirdz
Sorry, brainfart!

------
kruhft
I used to do this:

    
    
        emacs --batch --eval '(dump-emacs "em" "/usr/local/bin/emacs")'
    

This would load everything from your .emacs file into a fresh executable that
would then start instantly.

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.

------
weavie
Moving to Emacs from Visual Studio means that I am amazed at how quickly it
starts up even without any optimization.

------
Walkman
Spacemacs solves this by lazy loading every package possible:
[https://github.com/syl20bnr/spacemacs/blob/master/doc/DOCUME...](https://github.com/syl20bnr/spacemacs/blob/master/doc/DOCUMENTATION.org#goals)

~~~
evilduck
Spacemacs still starts up really slowly compared to vim and roughly equivalent
plugins delivering similar features.

~~~
khgvljhkb
No, vim does not have anything that comes close to the killer feature (and
only good feature) of Emacs: lisp.

~~~
pyre
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.

~~~
jbssm
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._

------
zeveb
I too run emacs via systemd, and have emacsclient bound to a convenient
shortcut in my window manager. It's just wonderful.

------
nodivbyzero
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_known_steps_to_speed_up_emacs_start/)

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

------
erikcw
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](https://github.com/syl20bnr/spacemacs#os-x)
[1] [https://github.com/railwaycat/emacs-mac-
port/blob/master/REA...](https://github.com/railwaycat/emacs-mac-
port/blob/master/README-mac#L210-L213)

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

~~~
Semiapies
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.)

------
joosters
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!

------
davexunit
Just use 'emacs --daemon'!

------
curiousdude99
Run emacs as a daemon and use emacsclient. Instant startup!

------
jussij
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?

~~~
chipaca
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.

~~~
pyre
> 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.

