From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15679 invoked by alias); 3 Oct 2009 19:00:03 -0000 Received: (qmail 15535 invoked by uid 22791); 3 Oct 2009 19:00:01 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-bw0-f208.google.com (HELO mail-bw0-f208.google.com) (209.85.218.208) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 03 Oct 2009 18:59:57 +0000 Received: by bwz4 with SMTP id 4so1753187bwz.24 for ; Sat, 03 Oct 2009 11:59:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.102.178.9 with SMTP id a9mr1542350muf.91.1254596394293; Sat, 03 Oct 2009 11:59:54 -0700 (PDT) In-Reply-To: <19142.34895.136190.624637@totara.tehura.co.nz> References: <8ba6bed40910021037q16276bb7w83ec3a5f20e2cbd1@mail.gmail.com> <19142.34895.136190.624637@totara.tehura.co.nz> Date: Sat, 03 Oct 2009 19:00:00 -0000 Message-ID: <8ba6bed40910031159v6508a55ap4fd02b253c599794@mail.gmail.com> Subject: Re: [patch/rfc] mi interpreter-complete enh req 8058. From: Matt Rice To: Nick Roberts Cc: tromey@redhat.com, gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00091.txt.bz2 On Fri, Oct 2, 2009 at 4:10 PM, Nick Roberts wrote: > PR 8058 goes back to 2003. =A0I don't see the need for MI to duplicate al= l of > the CLI functionality. =A0Emacs just uses the CLI command "complete" whic= h is > clearly just intended for front end use: > > complete b ma > &"complete b ma\n" > ~"b main\n" > ~"b malloc\n" > ~"b malloc@plt\n" > ^done > > The lisp function, gud-gdb-complete-command. is bound to TAB to it works > in the GUD buffer (Emacs' console) just as it does on the command line. Thanks, I had missed this CLI command somehow, it will work for now, ideally i would like it not to be going directly to stdout like that output infers, I guess i could change the output filehandle, when executing this command until it finishes, so that the output history isn't filled with this temporal information which always bothers me... additionally its worth noting the patch screws this output up.