Hacker News Reader

Comment by saulrh | Hacker News Reader

Slow emacs startup isn't a problem thanks to the new emacs-server stuff. Running emacs with the "--daemon" flag will cause it to do initialization, fork into the background, and become persistent; now edit files using commands like "emacsclient $filename". Eamcsclient will connect to the daemonized emacs server and have it open $filename, bringing it forward either in an existing frame or (using the "-nw" or "-nc" flags) creating a convenient new frame to edit with. Not only does this give you the ability to get into emacs without going through init, the server will maintain all of your editing in the same process so you don't have to manage editor instances.

View on HN

Slow emacs startup ... people restart their emacs?

There are serious problems trying to run it as a server on Mac OS X. Basically it's not a real option on this platofrm.

I run Emacs on Mac OS X as a server. What I don't do is "emacs --daemon". I launch Emacs and then "M-x server-start RET". This seems to avoid any weird issues.

I use the "ec" script show here: http://emacsformacosx.com/tips

alias edemon='/Applications/Emacs.app/Contents/MacOS/Emacs --daemon"

will give you a more helpful alias.

I've been running emacs server for at least a year or two now on OSX using homebrew.

  "$(brew --prefix)/opt/emacs/Emacs.app/Contents/MacOS/Emacs" --daemon

Huh. This works for both -t and -c in emacsclient, with a vanilla build of pre-24.4. It didn't for ages, so thanks for getting me to check this out again!

I'm not very familiar with OS X, and I've had a lot of trouble finding the magic invocation that'll get an Emacs daemon running with the same behavior to which I'm accustomed on Windows and Linux. This looks like it should do the trick, thanks! Now if only I could get emacsclient to behave sensibly in the dock, I'd really be cooking with fire...

I wish I could muster the energy to figure out how going that particular route is flawed. I just know that it's one of the ones I tried, and I learned the hard way that it's got problems.

If you accidentally quit the Emacs GUI, does it still kill the daemon?

If you run it with --daemon, the server process doesn't create a frame of its own, but only listens for connections from emacsclient instances; IIRC it also rebinds C-x C-c to delete-frame (also available at C-x 5 0), and the daemon process stays alive through everything short of M-x kill-emacs or similar.

I have this:

    ;; schedule starting of Emacs server after everything else is loaded (5 min
    ;; *should* be anough for startup :))
    (run-at-time "5 min" nil 'server-start)

in my .emacs - this way I get both a window and a "daemon" server for use with emacsclient. I think it dies if the first frame is closed, though.

You can actually just put

    (server-start)

at the end of your init file, and it'll behave more or less as you intend; if you've got a lot of stuff hanging off after-init-hook, you might do well to hang server-start off it as well.

That said, yeah, it will create a window which if killed will shut down Emacs, so I tend to prefer invoking it with the --daemon option instead; that way, I don't have to worry about accidentally killing Emacs if I kill the wrong frame. (I also call server-start in my init file, but I'm not actually sure that is necessary when invoking Emacs with --daemon.)

If you're on a Mac (as I am) it leaves an Emacs application running (complete with menu bar and app switcher icon) that you can't interact with. But otherwise, --daemon works great.

I'm on Mavericks running Emacs 24.3 installed through `brew`. I invoke `emacs --daemon` once when I start work and I have an alias and an Automator workflow to open files in GUI `emacsclient`s. No problems at all. What sort of issues are you seeing?

Reply on news.ycombinator.com