Stop Waiting for Emacs to Start: Use the Daemon and emacsclient
Starting Emacs for every git commit or quick edit wastes seconds. Running a single Emacs daemon and connecting with emacsclient gives near-instant frames and shared state across GUI and terminal.
16 May 2026, 11:42 UTC

Running git commit and waiting three seconds for Emacs to cold start is the concrete problem server mode solves. The useful takeaway is to keep one long-running Emacs process and open new frames with emacsclient. Subsequent edits appear in milliseconds and share buffers, kill-ring and customizations across GUI and terminal clients.
Why a cold start hurts frequent edits
Emacs loads init files, packages and font caches on startup. For an interactive desktop session that cost is amortized, but for short-lived invocations from the shell it dominates. The $EDITOR used by git, tig or crontab -e is a classic case: you want the editor immediately, not a startup sequence.
Server mode decouples the editor process from the frame. The daemon holds the state; clients are thin connections.
How Emacs server mode shares one process
Emacs can run as a daemon with emacs --daemon or interactively with M-x server-start. Once running, it listens on a socket in the user’s runtime directory. emacsclient connects to that socket.
emacsclient -copens a new GUI frame. Requires an X display or Wayland socket accessible to the user.emacsclient -topens a terminal frame inside the current terminal. Useful on SSH or headless hosts.emacsclient -nwforces a terminal frame even if a display is present.
All buffers, kill-ring, registers and customizations live in the daemon. Editing a file in one frame instantly reflects in another because there is only one buffer object.
Server mode has been part of Emacs since version 22 and is provided by the built-in server package. Recent distributions often ship a user service that starts the daemon on login.
Worked example: daemon for $EDITOR and desktop
Start the daemon once per login session as the regular user, in a terminal:
emacs --daemonExpected check: the command returns without error and a single Emacs process remains running. You can verify with ps -ef | grep emacs and observe one daemon process persisting.
Open a GUI frame from the desktop or terminal:
emacsclient -cOpen a terminal frame for shell use:
emacsclient -tMake the daemon the default editor for command-line tools. In your shell rc file add:
export EDITOR='emacsclient -t -a ""'The -a "" argument tells emacsclient to start the daemon automatically if it is not running. Risk: automatic start can hide a misconfigured daemon path, so verify the daemon is the one you expect.
Verify shared state. Edit a file in the GUI frame and save it. In another terminal run:
emacsclient -e '(buffer-file-name)'Expected check: the evaluated form reports the file currently visited in the selected buffer of the daemon, confirming the client is connected to the same process.
Trade-offs and limits
The daemon is a single point of failure. If the Emacs daemon crashes or is killed, all connected clients lose unsaved buffers unless auto-save or save-buffers-kill-terminal is configured. Enable frequent auto-save and consider kill-emacs-hook to prompt for saves.
On headless servers, GUI frames cannot be created without a display. Use -t or -nw to avoid X dependencies. File names and socket paths are user-specific; do not run the daemon as root and connect as an unprivileged user.
Startup latency moves from every invocation to once per session. The first emacs --daemon still pays the full init cost. Subsequent emacsclient connections are near-instant.
Close the session cleanly with emacsclient -e '(kill-emacs)' or emacs --daemon --eval '(kill-emacs)' to avoid orphan sockets.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.