CGDB - a curses debugger

CGDB
A curses debugger

Current Proposal for CGDB 1.0

The CGDB GUI should have the following features:

Configurable:
- Config file containing :ex commands
  - Any commands that can be typed in status bar is acceptable. Commands that don't make sense before CGDB is initialized should be ignored.
- Key bindings for any :ex commands
  - I think this should be done through :map commands, but this is open for discussion currently.
- Vim-style interface
  - Support running commands n times by typing a number n before a keystroke command.
- Color schemes
  - Again, Vim-style, with a file named ~/.cgdb/colors/myscheme, and loadable by executing "color myscheme". Maybe we should even handle Vim's exact format, so people can just copy their Vim files to .cgdb.
- Border schemes
  - Many terminals do not support nice borders. CGDB needs to be able to show the user what is necessary without any special terminal characters. Although they are nice, they should not be necessary or hard coded.
Robust source viewer:
- Fast syntax highlighting
- Regular expression searching
- Token identification (for displaying data)
  - A part of this requirement is that the cursor must be movable in both directions (row, column), so that the user can select a token for an arbitrary action, such as a search, or data display.
- Assembly view (source, asm, and mixed modes)
- Hyperlinking (for viewing help files)
- Configurable
  - The source viewer should have certain attributes which can be controlled via the :set function (i.e. wrap, ignorecase, tabsize, etc).
Windowing system:
- Arbitrary number of source windows
- Bindable to currently executing source
- Resizable. Movable?
- Inferior process window (tty)
Macro support (vim-style)
Support reloading a new inferior program (gdb 'file' command)

The TGDB library should have the following features:

GDB Interfaces
- Annotate 2
- GDB/MI
- Easily Extensible
  - Support easy plugging in of alternate methods for future versions, such as Annotate levels 1 and 3.
Support for advanced GUI features
- Reloading new inferior application
- Providing a TTY for the inferior window
- Providing assembly instruction as well as file:line info
Stable API
- Part of this is making the TGDB library context-driven, so that multiple instances of GDB can be invoked by a GUI. Because of this, TGDB should not handle signals automatically, unless the GUI code requests it.
Context driven readline style interface to GDB console
- TGDB is responsible for dealing with the users command line interaction. This is because it simplifies the GUI's responsibility. The GUI should know nothing about how TGDB allows the user to interface with GDB's console.
Support for sending and receiving data to the inferior process
Annotate 2 possibilities:
- TGDB handles both directions of communication.
  Using the tty command to do input and output with inferior.
- TGDB handles the output of the inferior.
  Just receiving the output of the inferior if no tty is available. Sending input to the inferior is not possible.
- TGDB doesn't handle communication with the inferior at all.
  Allowing the user to attach to the inferior process. If this is the case, the input and output to the inferior will go to the terminal it started in.