Re: Debugging Emacs

[phillip.lord@russet.org.uk (Phillip Lord)]

Eli Zaretskii <eliz@gnu.org> writes:

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

Perhaps I am being thick, but I tried C-z and AFAICT it does nothing. I
mean, where do I type C-z? In the debugged Emacs? In the Emacs running
gdb?



>> 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 ;-)

Yeah, I know. "Hello World" is important though.


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

I'd welcome simplification. Having a brief run though that anyone could
follow till they have a breakpointed Emacs would help. I'm no expert, so
need feedback on anything that makes it shorter.

> And I'm not sure why it's important to mention "ppt", but not a
> gazillion of other useful functions in .gdbinit.

It's not. I mention "pp" because I think it's really important. To
mention one useful function is not enough though, you need to mention
another so you can say there are many other functions and you should
read .gdbinit. I chose ppt because it seemed to make the point well (bad
pun!).

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

Ah, of course. Same window in gdb-many-windows!

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

Unconvinced. The single large manual is also on the web and it's easier
to find there than as a file in etc/DEBUG. I tried searching for "Emacs
debug with GDB" and various other combinations before I found etc/DEBUG.
Which I found because you described it on Emacs-devel.

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

I agree. I just mentioned it in passing!

Phil