[Cgdb-devel] cgdb's future

[Bob R. <bob...@co...>]

Hi all,

I have been thinking a lot about cgdb lately. I have come up with a set
of problems that must be solved correctly before the next release. I
believe once these problems are solved we will have no problem working
on cgdb in the future. These are problems are not easy to solve and
require making design and feature decisions about cgdb.

I would really appreciate it if you guys would sit and think about these
problems. Maybe coming up with alternate solutions I have not though of.

The basic problems are:
1. Getting ESC sequence input
2. Getting readline to work in cgdb
3. Getting multiple readline sessions working in cgdb

1. Getting ESC sequence input

Problem:
cgdb uses getch to get input from the user. This translates all the ESC
sequences simple. This is great when the user is at the 'cgdb window'.
However, when the user is at the 'gdb window' cgdb passes all data to
readline. So, it can no longer call getch() as readline would not be
happy receiving 'KEY_UP' instead of its ESC sequence. It works if we
just let readline read from stdin when we are in 'gdb mode' but cgdb
will never know if the user hit pgup pgdn when they are in that mode.
I don't think this is very good. I think cgdb should always understand
the ESC sequence the user is trying to user.

Proposed Solution:
a. I think instead of re-writing the input library getch(), we should still
use it. However, if the we do find out that the user hit KEY_UP in the
lower window, we look up the ESC sequence in the terminfo/termcap
library and send it to readline. This saves us from rewriting a
substantial amount of non-trivial code.

b. We could write an input library. readline does it and its easy to
extract. It would still take some time though. At least a month.

2. Getting readline to work in cgdb
Problem:
readline doesn't work the way the documentation says it does.
   Function: void rl_callback_read_char (void)
   Whenever an application determines that keyboard input is available,=20
   it should call rl_callback_read_char(), which will read the next=20
   character from the current input source.

This is true. However, it fails to mention that it will read more than=20
1 char. When ^r is typed it tried to read every char up until the '\n'.
So, since there is no more data on readline's input, it blocks.
This causes cgdb to hang.=20

Proposed Solution:
cgdb can no longer use the alternative interface.=20

a. If we let readline read from stdin, instead of its stdin ( pty I create =
).
This will stop the blocking problem. Since when the user types it would
satisfy readline. However, cgdb would no longer know the ESC sequences
the user typed. so pgup and pgdn would no longer work in the bottom
window.

b. We could make cgdb multi-threaded so it wouldn't block. This seems
non-portable and over complicated to me for some reason.

c. We could make an abstraction to readline. This abstraction would
fork-exec a program that we write. This program would basically just be
around for readline support. That way, cgdb wouldn't hang. Look at next
problem that makes this solution desirable to me ( even though it is
grossly inefficient).

3. Getting multiple readline sessions working in cgdb
Problem:=20
cgdb is trying to use more than one readline at a time. It wants to use
a readline at the 'gdb window' and at the 'status bar'. readline does
not support multiple invocations of itself within a single program. We
could almost kludge it but calls to add_history() would affect each
other. When the user is at the status bar and types KEY_UP then they
would get the commands entered at the gdb window.

Solution:

Don't have multiple invocations of readline in one application.

a. Make libtgdb an application instead of a library. It would have its
own readline. This solution would then still make cgdb multi-threaded to
avoid its blocking problem.  ( I really don't like this idea ).

b. Don't let the 'status bar' have readline support. Ever.=20
( I really don't like this idea ).

c. Make the abstraction to readline, where for every instance of a
readline we want we just fork and exec a new program. I really don't
think the over head of this solution would be terrible, considering the
problems cgdb is facing. ( I really don't like this idea :), but I like
it better than the others ).



Anyways, these are major problems. They need to be solved. Any help
would be awesome.

Thanks,
Bob Rossi