Re: [Commit] New file

[Andrew Cagney <cagney@gnu.org>]

Yes.

My take of this is that IMHO the code in gdb-mi.el will bit-rot on the
Emacs side much faster than on the GDB side.  That is because the
GDB/MI API is supposed to change/evolve much slower than the Emacs
features related to gdb-mi.el.
It's true that GDB release cycle is much frequent than the Emacs
release cycle, but OTOH the pace of code changes checked into the
Emacs CVS is much faster than that of GDB.  Specifically, many
display-related features for which gdb-mi is an ideal application were
introduced during the the last couple of months alone.  There's no
comparable change in the MI interface and/or features.

With GDB's more frequent release cycles there's a greater oportunity
to expose the code to a wider audience.


As the Emacs CVS is accessible by anonymous, it's very easy to get the
latest gdb-mi.el.  So this is a non-issue, I think.
Here's the catch.  It isn't the existing GDB/MI API at issue here, it's 
the new/missing interfaces needed to reflect ongoing changes in GDB:

- support for frame IDs
- support for register groups
- support for event notifications
- a fix to that ``query'' problem
- ...
along perhaphs with:

- support for NxM breakpoints (if they happen)
- proper event notification (ongoing)
It's going to be a lot easier if both the client and server are there in 
front of us.

(For me personally, I'm not going to rush out and down load the latest 
emacs, however I will be comfortable with using the latest gdb-mi.el 
with a recent emacs release.)

Andrew