From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26069 invoked by alias); 22 Jun 2005 03:41:25 -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 26061 invoked by uid 22791); 22 Jun 2005 03:41:21 -0000 Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 22 Jun 2005 03:41:21 +0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j5M3fJeE029789 for ; Tue, 21 Jun 2005 20:41:20 -0700 (PDT) Received: from relay1.apple.com (relay1.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Tue, 21 Jun 2005 20:41:19 -0700 Received: from [17.201.22.21] (moleja.apple.com [17.201.22.21]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id j5M3fFTh019220; Tue, 21 Jun 2005 20:41:16 -0700 (PDT) In-Reply-To: <20050622033214.GA22609@nevyn.them.org> 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> <20050622033214.GA22609@nevyn.them.org> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <11222BEA-D272-4170-B4FD-885E184D1065@apple.com> Cc: Nick Roberts , Eli Zaretskii , gdb-patches@sources.redhat.com Content-Transfer-Encoding: quoted-printable From: Jason Molenda Subject: Re: [PATCH] MI error messages Date: Wed, 22 Jun 2005 03:41:00 -0000 To: Daniel Jacobowitz X-SW-Source: 2005-06/txt/msg00344.txt.bz2 On Jun 21, 2005, at 8:32 PM, Daniel Jacobowitz wrote: > I'm not sure what you're agreeing with here. Sorry, you're right, I wasn't being clear. > 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. Agreed. Honestly I don't know if there are any deployed GUIs that=20=20 use MI except for Xcode -- I hear Eclipse does -- but I can imagine a=20=20 (poor) implementation dropping the ^error message text on the floor=20=20 and assuming that the user will see the error message in the gdb =05=12I/=20 O window. > I strongly disagree with outputing unformatted errors > as in Nick's first example, though. Yes, I agree that outputting unformatted errors is a bad idea. J