From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26758 invoked by alias); 12 May 2006 22:14:54 -0000 Received: (qmail 26750 invoked by uid 22791); 12 May 2006 22:14:54 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao01.cox.net (HELO eastrmmtao01.cox.net) (68.230.240.38) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 12 May 2006 22:14:51 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao01.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060512221449.LTHY17255.eastrmmtao01.cox.net@localhost.localdomain>; Fri, 12 May 2006 18:14:49 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1Fefv1-0000eL-Bb; Fri, 12 May 2006 18:15:31 -0400 Date: Fri, 12 May 2006 22:19:00 -0000 From: Bob Rossi To: Nick Roberts Cc: Eli Zaretskii , ghost@cs.msu.su, gdb-patches@sources.redhat.com Subject: Re: CLI and GDB/MI documentation patch Message-ID: <20060512221531.GA1741@brasko.net> Mail-Followup-To: Nick Roberts , Eli Zaretskii , ghost@cs.msu.su, gdb-patches@sources.redhat.com References: <17509.54397.736467.479414@kahikatea.snap.net.nz> <17509.943.40875.198555@farnswood.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17509.943.40875.198555@farnswood.snap.net.nz> User-Agent: Mutt/1.5.9i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00268.txt.bz2 On Sat, May 13, 2006 at 09:52:47AM +1200, Nick Roberts wrote: > > > Putting these things in the manual just makes it harder to change GDB. > > > I would rather say: "Its there. Use it at your own risk". Or at least: > > > > > > > > > For the developers convenience CLI commands can be entered directly. > > > However this feature may be removed at some stage in the future and > > > it is recommended that front ends use the @code{-interpreter exec} command. > > > @xref{GDB/MI Miscellaneous Commands}. > > > > Do we indeed intend to remove this feature any time soon? If so, I > > agree that we should add a warning about that. > > I don't know about any time soon buts it's clearly irregular and I guess > could interfere with the design of MI. Also it doesn't have to stay as > -interpreter exec provides an alternative. > > But, other than that, > > why do you say that describing the CLI support in mi in more detail > > will make it harder to change GDB? > > Because if people write a front end that relies on a feature then understanably > they are upset when it is changed or removed, just as I was when it appeared > that annotations would be removed. The one advantage of Emacs long > release cycle is that it gives you more time to get everything right before > its released. GDB goes out about every six months along with an expectation > that its behaviour will some level of maintenance. I agree with you completly. What if we released mi3 with the next release of GDB. We could remove the direct CLI commands then. I think there would be some advantages to releasing mi3 anyways. The good news for FE developers, is that a very quick fix on there side should allow them to be working again. Bob Rossi