obsoleting annotate level 2

[Bob Rossi <bob_rossi@cox.net>]

Hi,

I have been writing a front end to gdb called cgdb. It depends on gdb's
annotate level 2 feature. This project can be downloaded at
cgdb.sourceforge.net. Before that it was hosted at tgdb.sourceforge.net.

It is a curses front end to gdb that is intended to be lightweight and
responsive. I originally wrote cgdb because I use gdb, sometimes for
several hours, during the day at work. We use GNAT's version of gdb
which seems to be behind GNU ( As far as version and features ).

I decided to make it a curses front end because there are many times
during the day when I ssh into a window's box using cygwin.

At the time I started developing cgdb ( about 8 month's ago ). I began
looking into how to interface with gdb without losing any of the
command line power. I began looking into how other debugger's did it.
So I soon realized that xxgdb, ddd and gvd all used annotate level 1.
I then did a little more research and discovered
http://www.gnu.org/manual/gdb/html_chapter/gdb_21.html#SEC203 which
encouraged me to use annotate level 2. Since even NOW, the manual says
nothing about annotate level 2 being deprecated, but describes how to
use the annotations.

I used annotate 2 to interface to gdb for several reasons:
   1. gdb-mi is not in older versions of gdb. Including GNAT's version
      of gdb ( which we use at work ). If I wrote a front end using this
      the gdb-mi feature of gdb, I would not be able to debug programs
      with GNAT, cygwin, red-hat, suse ... out of the box distributions.
      This seems UNACCEPTABLE.
   2. gdb-mi does not have readline support at the command line.
      This is an important feature if the GUI wants to keep gdb's
      useful command line feeling 100%.
   3. gdb-mi did not ( at the time ) support the CLI commands.
   4. annotate level 2 gave much more information to the GUI over
      annotate level 1. Including:
      1. When the user is interfacing with the readline library.
      2. When the breakpoints need to be checked (instead of every time).  
      3. The prompt can change. the debugged program can output the
      string '(gdb) ' to stdout without breaking the GUI.
      4. I was able to allow the user to communicate with the debugged
      program, no matter how the debugged program sets the terminal.
      ex. ( cbreak, raw ...)

I feel that cgdb should be separated from gdb for several reasons:
   1. cgdb should support a rich variety of options including
      1. macro support
      2. key bindings that do not have to be Emacs style
      3. configuration file for syntax color support ...
      4. regular expression searching
      5. many more options that can make cgdb easier to use.
   2. Users should not have to recompile gdb to get curses support.
   3. I can write cgdb knowing nothing about the internals of gdb,
      without sacrificing the risk of bugs in gdb for a GUI.

With these things in mind, I understand that gdb must move on. With or
without cgdb. Eventually cgdb will support gdb-mi. My only claim is that
gdb keep supporting annotate level 2 until it is ready to remove both
annotate level 1 and 2.

This way when other programs like gvd, ddd and xxgdb are rewritten to 
use gdb-mi and not annotate level 1, then programs like cgdb and
possibly others can be rewritten as well. I know these programs will use
gdb-mi when it is stable and ready. Util then, I don't think annotate
level 1 or 2 should be removed since there are existing front ends to gdb
that use them.

I believe this is fair. In fact, I am even willing to support annotate
level 2 if necessary. I know I have no association with GNU, but I would
be willing.

Thanks,
Bob Rossi