4

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

Take YoungFrog's advice:

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

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

  1. unalias emacs. I thought, maybe starting the debugger might involve calling emacs, and be getting hosed by my alias. Empirically, no change.

deprecated options

  1. Recompiling Emacs with debug symbols. That seems like a lot of work.
  2. 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
TomRoche
  • 592
  • 3
  • 20
  • What I do is restart Emacs without --daemon, then debug, and finally restart as --daemon. – YoungFrog Sep 28 '16 at 04:45
  • @YoungFrog: Thanks! See [answer](http://emacs.stackexchange.com/a/27406/5444) (err ... workaround ... but it's all I got right now) below. – TomRoche Sep 28 '16 at 06:09

2 Answers2

1

You could use a custom wrapper script as your -a argument value, but you presumably only want to use --debug-init temporarily, so... just do that.

Kill your Emacs server if it's running, and then restart it with --debug-init.

emacs --daemon --debug-init

Now connect to it as usual.


edit: TomRoche adds the following...

Note that, if this throws an immediate error, like

emacsclient: unrecognized option '--daemon'

you may have aliased emacs: check that with (in bash)

alias emacs

If you have an alias, you can either delete it (with unalias emacs) or temporarily override it by preceding the alias with a backslash, e.g.,

\emacs --daemon --debug-init
phils
  • 48,657
  • 3
  • 76
  • 115
0

Not quite an answer, but the only currently-working workaround is, take YoungFrog's advice:

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); debugger will work.

2. Use {"classic" startup, debugger} to resolve all startup problems.

3. Once session will load without error with emacs --debug-init, return to starting sessions with emacs --daemon.

TomRoche
  • 592
  • 3
  • 20