From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23215 invoked by alias); 22 Jun 2005 03:32:27 -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 23203 invoked by uid 22791); 22 Jun 2005 03:32:23 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 22 Jun 2005 03:32:23 +0000 Received: from drow by nevyn.them.org with local (Exim 4.51) id 1DkvyI-0005vv-F1; Tue, 21 Jun 2005 23:32:14 -0400 Date: Wed, 22 Jun 2005 03:32:00 -0000 From: Daniel Jacobowitz To: Jason Molenda Cc: Nick Roberts , Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [PATCH] MI error messages Message-ID: <20050622033214.GA22609@nevyn.them.org> 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.5.8i X-SW-Source: 2005-06/txt/msg00343.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. I'm not sure what you're agreeing with here. I think it makes plenty of sense to update error handling to just show the ^error, not &"..." also - though that is an incompatible change and would need some wider testing. I strongly disagree with outputing unformatted errors as in Nick's first example, though. We have a syntax for error messages... let's use it? -- Daniel Jacobowitz CodeSourcery, LLC