Re: obsoleting annotate level 2

[Bob Rossi <bob_rossi@cox.net>]

I understand that we will have to support both interfaces to gdb. That
is not the issue at all. The issue is, annotate level 2 and 1 should not
be removed from gdb because existing software relies on them.

That is why you are leaving annotate level 1, is that correct?

Thanks,
Bobby       

On Tue, Feb 04, 2003 at 11:34:31AM -0500, Elena Zannoni wrote:
> Peter Kovacs writes:
>  > On Tue, Feb 04, 2003 at 10:53:51AM -0500, Elena Zannoni wrote:
>  > > Interesting, I don't know if you are aware, gdb has already a curses
>  > > interface. configure gdb with --enable-tui and invoke with --tui.
>  > > 
>  > > Documentation is at:
>  > > http://sources.redhat.com/gdb/current/onlinedocs/gdb_22.html#SEC197
>  > > 
>  > > Would it make sense to unify the efforts? Even though i see you want a 
>  > > completely separate UI.
>  > 
>  > I am also a developer on the cgdb project.  We discussed to some length
>  > the possibility of unifying the efforts and we decided it might not be
>  > such a good idea because:
>  > 
>  > 1. We need to use cgdb with older versions of gdb such as
>  >    4.17.gnat.3.14p-1, which we've standardized on here at work.
>  > 2. We wish to keep future compatibility with other console debuggers
>  >    (perl -d, jdb, etc).
>  > 
>  > Really point #1 is a deal-breaker for us.  It is basically the entire
>  > reason we started this project.  We do hope that cgdb can be written in
>  > such a way that it could become the default curses front-end to gdb, but
>  > we certainly don't want to step on any toes in that regard.
> 
> If you have to keep supporting the old gdb, you will need to support
> two interfaces to gdb. Unless you are importing MI into
> 4.17.gnat.3.14p-1. If you have no control over 4.17.gnat.3.14p-1, and
> supporting that is your primary goal, I don't see what FSF gdb can do
> to correct that, ie I see two conflicting goals here.
> 
>  > 
>  > As for the MI issues, I think we'd be willing to move over to the MI
>  > interface if and when it supports some of the readline style of input.
> 
> About readline, there was a conscious design decision to not provide
> it with MI, because the editing capabilities would be implemented at a
> different level, in the GUI console, not in gdb. With the interpreter
> changes the console becomes now a concrete possibility.  BTW, you may
> want to take a look at Apple's Project Builder, I don't know what
> level of editing they provided with their console.
> 
> elena
> 
> 
>  > Cgdb is designed to offer *everything* that gdb does plus some extras
>  > (source view, break points, shortcut commands).  I'm not entirely sure
>  > what work has been going on in this area, as I've just recently started
>  > paying attention to this list.  
>  > 
>  > Thanks,
>  > Peter Kovacs
>  > 
>  > -- 
>  > Peter D. Kovacs <peter@kovax.org>