Re: Debugging Emacs

[Eli Zaretskii]

> From: address@hidden (Phillip Lord)
> Cc: <address@hidden>,  <address@hidden>
> Date: Thu, 10 Dec 2015 22:36:32 +0000
> 
> > 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?

Into the Emacs window, like DEBUG says.

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

Alas, there is no simplification I could think of.

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

It can only be longer, if we want it to be relevant.  The simplest
debugging scenarios are too diverse to allow a short introduction that
is useful.  See the "Sample Session" node in the GDB manual for what
such an introduction looks like.  We could point to that if you think
it will be useful.  Or we could have something similar (but specific
to Emacs) in DEBUG, but then it cannot be in the preamble, it should
be elsewhere, and the preamble could refer to it.

One other thing to keep in mind is that having documentation that is
too closely tied to the current source (e.g., quoting function and
variable names) is a certain maintenance burden, since functions and
variables are routinely renamed, moved to other places, and deleted as
part of development, and we then have yet another file to keep in sync
with that.  Not rocket science, just one more thing to consider when
deciding whether this is worth the hassle.

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

Everything except "ppt" is still there, including "pp" and the
reference to a later section where other commands are described.

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

It's mentioned in CONTRIBUTE, FWIW.  That should be the first place
people look for this information.  I don't know how to advertise it
better, and I very much doubt having it in the manual will do the job:
look at how many questions get posted that are already in the manuals.