[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Debugging Emacs
From: |
Eli Zaretskii |
Subject: |
Re: Debugging Emacs |
Date: |
Mon, 07 Dec 2015 18:34:08 +0200 |
> 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.