obsoleting the annotate level 2 interface

[Nick Roberts]

 > Nick, what is involved in bringing gdb-ui over to using MI?

A dialogue is a good starting point. I'm slightly surprised at the
lack of communication between GDB and Emacs developers given the common
heritage.

I think writing a mode for Emacs that uses MI would require quite a different
approach to gdb-ui.el. Think of what was involved in `bringing GDB over to MI'
(a lot of work, I would imagine).

 > Annotations have been deprecated for a while now, so it probably won't
 > kill us to keep them for a while longer, but it doesn't make sense for
 > us to keep them indefinitely; gdb-ui needs to start making the
 > transition.

I think this is what has baffled a lot of GDB users. There are something like
39 problem reports open for MI and only 14 closed (I'm hesitant to say this as
I applaud the transparency of the system and I don't want to encourage
secrecy). We don't see how the GDB developers can deprecate annotations or
encourage users to switch to MI until it is ready.

For my part, I will start to look at MI again. It appears that it has undergone
a lot of development since I looked at it last year. GDB developers could
help this process (not just for me, but all users) by ensuring that the
documentation for MI is bang up to date.

 >                                                      But from what I
 > do understand, I really think MI is the way GDB should go. 

I think everyone accepts this. It is just the timing that is being questioned.

 > Personally, I want a command-line interface to GDB too; I'd like to
 > see MI used to improve that (say, by handling 'display' or the
 > breakpoint list better), but I don't want to replace it.  What is MI
 > missing in this regard?  It seems to me like it's all there:
 > 
 >   zenia:emacs$ $D6/gdb/gdb --interpreter=mi2 $D6/gdb/gdb
 >   ~"GNU gdb 2003-01-23-cvs\n"
 >   ...

I've only looked at GDB 5.0 (GNU gdb 20010813 (MI_OUT)). It doesn't seem to
have mi2. I didn't spend much time looking at MI, I'm just one person,
dabbling in my spare time. I saw that annotations did what I wanted and I ran
with it. I don't think that I could have taken MI as far with such limited
resources.

 > What are the other issues?

At the time, streams didn't seem to work. I couldn't seem to generate the @
prefix output. That's probably changed now. I can't really say much more
until I have something concrete to experiment with.

 > This may not be the largest issue, but one thing that might be of
 > interest is that, given the way the MI support is done, it would be
 > very easy to have GDB provide all its output as Emacs Lisp
 > s-expressions, so Emacs could just 'read' them directly.  And this
 > would be a modular and relatively small change.  All you need to do is
 > provide your own `struct ui_out_impl' that prints things the way you
 > like.

I don't know what form it should take but I do think that GDB should hook into
Emacs in some way and that they appear to have drifted apart.

I have never seen the source for GDB. Perhaps you can explain why annotations
is difficult to maintain. In my limited experience, I have found that two 
features in a program can often be orthogonal to one another. That is, one
feature can be developed as if the other feature isn't there. 

Also gdb-ui.el probably doesn't need all the annotations. If you lost some key
ones (frames-invalid and breakpoints-invalid, for example) would this make it
easier to maintain?

Nick