summary
problem
I'm trying to debug a problem that involves an Emacs config and daemon startup. But when I run
emacs --daemon --debug-init
from a console, the spew ends with
Loading desktop from /home/me/.emacs.d/personal/ ...
Entering debugger...
and hangs until killed. How to make the daemon properly enter the --debug-init
(or other) debugger?
current workaround
0.
Consider emacs --daemon --debug-init
to be broken WRT this usecase. (TODO: file emacs bug.)
1.
Start sessions with emacs --debug-init
(and not emacs --daemon --debug-init
).
2.
Debugger will work: use it to resolve all startup problems.
3.
Once session will load without error with emacs --debug-init
, return to starting sessions with emacs --daemon
.
detour
Another late-night brainfart :-(
I had tried to run
$ emacs --daemon --debug-init
(as later recommended by phils) and got the response
emacsclient: unrecognized option '--daemon'
Next morning I realized
$ alias emacs
alias emacs='emacsclient -c -a emacs'
and therefore that I needed to run (in bash)
$ \emacs --daemon --debug-init
# ^--note backslash needed to override the alias
which works ... except that it gives the problem described in section=summary
.
details
reproduction procedure
I'm running the GNU Emacs 24.4 GUI via daemon on a vanilla Debian stable=Jessie with minor bits of testing (none involving Emacs). I'm rebasing my old'n'crufty, non-package-using emacs config on Prelude as follows:
1. Old config (also a git repo, but private) is @ ~/.emacs.d__old_n_crufty/
2. New config (a Prelude fork) is @ ~/.emacs.d__Prelude/
3. When I want to check my old functionality, I do
pkill emacs # ensure daemon not running
rm ~/.emacs.d
ln -sr ~/.emacs.d__old_n_crufty ~/.emacs.d
ls -ald ~/.emacs.d* # sanity check
\emacs --daemon --debug-init # backslash to override alias
4. I copy bits of elisp from my old config to the new, then test latter with
pkill emacs
rm ~/.emacs.d
ln -sr ~/.emacs.d__Prelude ~/.emacs.d
ls -ald ~/.emacs.d*
\emacs --daemon --debug-init
Just to be excruciatingly clear: both configurations are running the same underlying Emacs version, and both are using daemon+emacsclient
. The only difference is the configs, i.e., the runtime ~/.emacs.d/
.
Old'n'crufty config works as expected: particularly, the spew in the console in which I run my startup scriptlet ends with
Desktop: 1 frame, [much too large number of] buffers restored.
Starting Emacs daemon.
Restarting server
Emacs daemon should have started, trying to connect again
Waiting for Emacs...
and then I see my GUI frame. New config was doing fine until I ported my desktop; now, console spew ends with
Loading desktop from /home/me/.emacs.d/personal/ ...
Entering debugger...
which hangs until C-c
. (Note also that both configs are using the exact same desktop file: 2 copies in different filetrees, no symlinks involved (yet, anyway).)
How to make the daemon start/enter the --debug-init
debugger properly? Alternatively, is there another debugger that plays better with the Emacs daemon, but which does not require major labor?
workarounds
- starting without daemon, i.e. just oldschool
emacs --debug-init &
. See this "answer", or section=current workaround
above (to which I'd link but SE apparently won't support section links).
failed options
unalias emacs
. I thought, maybe starting the debugger might involve callingemacs
, and be getting hosed by my alias. Empirically, no change.
deprecated options
- Recompiling Emacs with debug symbols. That seems like a lot of work.
Bisecting config. This is unnecessary, because I've been porting function from old'n'crufty config to Prelude-based config step-by-step, and I know exactly what is failing: it's loading my old desktop. What I want to investigate is,
- exact same Emacs version used for both cases
- exact same desktop file used for both cases
- old'n'crufty config can load that desktop with no error
- Prelude config hangs
entering debugger
with that desktop