bug#4375: 23.1.50; can't kill killed gud buffer

 > > Emacs 23.1 is always an option for those using older GDB releases.
 > 
 > Rather you mean "using gud-gdb is always an option for those using older
 > GDB releases" (we're talking about what to do for Emacs-23.2, so we
 > take for granted that the user will be using Emacs-23.2).
 > That might be good enough (I personally always end up using gud-gdb
 > since I've always found M-x gdb to be somewhat unreliable).

No I don't, I mean M-x gdb in Emacs 23.1 is always an option for those using
older GDB releases (although it may depend how old, gdb-ui.el is better with
6.4 and later but should work back to 5.0 from 2000).

M-x gud-gdb should work in Emacs 23.1.50 as it does in Emacs 23.1.

I don't know what you mean by unreliable, but over the years, in my
experience, M-x gdb has become more reliable.  Of course if you have a highly
customized environment, the results might be different and buffers might
appear in strange places.  If you are having problems, I would recommend
starting with gdb-many-windows nil and then the startup should be similar
gud-gdb except that you can set breakpoints/control execution in the margin
and see the breakpoint locations there.  Then you could display new buffers in
new frames, as and when needed, by using the pull down menu: GUD >
GDB-Frames-> <desired GDB buffer>.

 > > We used to do that with "--fullname" and "--annotate=3" but that caused
 > > problems when execution was started in the users .gdbinit file.  The two
 > > options are now invoked with separate functions (M-x gud-gdb and M-x gdb).
 > 
 > I know, but I still think this is a temporary workaround.  We should
 > document it well in some comments to make sure someone who wants to
 > attack the problem doesn't waste time going through the same problems
 > agains.

On the contrary, I would like to remove gud-gdb at some point in the future.

-- 
Nick                                           http://www.inet.net.nz/~nickrob