Re: Debugging Emacs

[Eli Zaretskii]

> From: address@hidden (Phillip Lord)
> Cc: Nicolas Richard <address@hidden>,  <address@hidden>
> Date: Mon, 07 Dec 2015 09:51:34 +0000
> 
> >> FWIW I use "killall -TSTP emacs", at which point gdb kicks in. (IIUC.)
> >
> > This was in etc/DEBUG, of course.
> 
> Actually, it wasn't!
> 
> etc/DEBUG
> 
> has a section called "Getting Control to the Debugger". The section
> BEFORE that mentions
> 
> kill -TSTP PID

We are miscommunicating.  I didn't mean "kill -TSTP", I meant its
equivalent C-z.  "kill -TSTP" is only needed when Emacs hangs or
infloops while already running under GDB.  By contrast, the sub-thread
to which I responded talked about ways to get control to GDB in
general, where I think C-z is a much more important and much easier
technique than "kill -TSTP".  Safer, too.

(Btw, AFAIK "killall -TSTOP" is better than TSTP, as the former signal
cannot be blocked or ignored.)

> Getting the PID of emacs is somewhat painful because I normally run two.
> And three when debugging. It didn't occur to me that I could safely run
> killall -TSTP emacs without trashing my other Emacs'
> 
> Again, this all sounds small, but getting to the debug "Hello World"
> needs to be as simple as possible.

And it's exactly for these very reasons that I think C-z is more
important than "kill".  I think it's reasonable to assume that newbies
to debugging Emacs won't necessarily need to start with a hung Emacs
that already runs under GDB, so this corner case can be left in its
corner section.  I wouldn't recommend newbies to use "killall" anyway.

> It's good. Slightly more detail that I would have added (less is more in
> a brief tutorial).

Thanks.  Where to stop is a judgment call: too short descriptions risk
to leave the perplexed in their confused state.

> I would put back my short "run through".

It makes the section longer ;-)

Seriously, though: the few steps you described there are quite
possibly not what the user will need to do, so I think it would get in
the way.  And I'm not sure why it's important to mention "ppt", but
not a gazillion of other useful functions in .gdbinit.

> Also, the section on "pp" needs to mention that this prints to
> standard out (this is true right?).

Good point, I added that.  (No, it writes to stderr, but on GNU/Linux
you can redirect it to a file.)

> Probably, etc/DEBUG needs to be replaced with a section in the elisp
> manual.

Somebody already mentioned that.  I don't think I agree: when you
debug, you need the instructions be available on the simplest medium
possible, so a plain text file is better than Info.  What's more
important, a single file with a distinct name is easier found than a
section in a large manual.

> Which probably needs to be renamed (Programming Emacs Manual?)
> -- I noticed the section on modules going in the other day which isn't
> very lispy!

We have a section on writing Emacs primitives, had it for a long time.
In fact, the entire Appendix E there is full of non-Lispy stuff.  So
that ship sailed quite some time ago.  I won't argue about the name;
it's for the FSF to consider anyway, since they are selling it as a
book.

The C parts of the dynamic modules documentation will probably
relocate to the same appendix; what's now is just a preliminary
version (as the commit log message indicates), to let people who track
the development have something at their disposal.

Thanks.