From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14460 invoked by alias); 22 Jun 2005 13:04:38 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 14432 invoked by uid 22791); 22 Jun 2005 13:04:31 -0000 Received: from lakermmtao07.cox.net (HELO lakermmtao07.cox.net) (68.230.240.32) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 22 Jun 2005 13:04:31 +0000 Received: from white ([68.9.64.121]) by lakermmtao07.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050622130423.JNBP28809.lakermmtao07.cox.net@white>; Wed, 22 Jun 2005 09:04:23 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1Dl4ty-00021n-00; Wed, 22 Jun 2005 09:04:22 -0400 Date: Wed, 22 Jun 2005 13:04:00 -0000 From: Bob Rossi To: Jason Molenda Cc: Nick Roberts , Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [PATCH] MI error messages Message-ID: <20050622130422.GA7745@white> Mail-Followup-To: Jason Molenda , Nick Roberts , Eli Zaretskii , gdb-patches@sources.redhat.com References: <17077.61587.164352.664225@farnswood.snap.net.nz> <17078.19977.660644.9978@farnswood.snap.net.nz> <20050620135108.GA29453@nevyn.them.org> <17079.14386.484824.134375@farnswood.snap.net.nz> <17079.57494.321274.96102@farnswood.snap.net.nz> <17080.35377.519988.619664@farnswood.snap.net.nz> <4B2E0CF3-987A-41E8-A2B3-0ADD6955DAF7@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B2E0CF3-987A-41E8-A2B3-0ADD6955DAF7@apple.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-06/txt/msg00352.txt.bz2 On Tue, Jun 21, 2005 at 02:59:11PM -0700, Jason Molenda wrote: > > On Jun 21, 2005, at 2:44 PM, Nick Roberts wrote: > > >I presumed mi_usage_error would call error. That way the error is > >caught and > >any cleanups and rewinds are done. However, you are right, it > >would be nicer > >just to get: > > > >(gdb) > >-stack-select-frame > >Usage: FRAME_SPEC. > >(gdb) > > > >instead of > > > >(gdb) > >-stack-select-frame > >&"Usage: -stack-select-frame FRAME_SPEC\n" > >^error,msg="Usage: -stack-select-frame FRAME_SPEC" > >(gdb) > > > >as these errors aren't intended for the user when the frontend is > >being used. > > > Yeah, we came to the same decision at Apple. When you throw error() > while in MI mode, you only get the ^error message, you don't get the > console-style &"..." with the same message. Our GUI has a little > status line at the bottom of the window where it shows the error > message, and if you have the "gdb console" window open, it shows the > error text in a different color to differentiate the error message. > It makes sense to let the GUI show the error in whatever way is most > appropriate for it, instead of blotting back plain old text. It would probably even make more sense if it the error message said something like, ^error,msg="Usage: -stack-select-frame FRAME_SPEC",reason=USAGE_NOTE That way, there is text associated with the error message, but the FE can also easily understand what type of error it is receiving, and perform different operations on that data. I can only guess that someone is doing a strcmp on that Usage message ... Bob Rossi