From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30457 invoked by alias); 10 Feb 2006 15:45:38 -0000 Received: (qmail 30391 invoked by uid 22791); 10 Feb 2006 15:45:37 -0000 X-Spam-Check-By: sourceware.org Received: from gandalf.inter.net.il (HELO gandalf.inter.net.il) (192.114.186.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 10 Feb 2006 15:45:37 +0000 Received: from nitzan.inter.net.il (nitzan.inter.net.il [192.114.186.20]) by gandalf.inter.net.il (MOS 3.7.1-GA) with ESMTP id HVI16463; Fri, 10 Feb 2006 17:45:22 +0200 (IST) Received: from HOME-C4E4A596F7 (IGLD-80-230-46-105.inter.net.il [80.230.46.105]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id CRF24473 (AUTH halo1); Fri, 10 Feb 2006 17:45:21 +0200 (IST) Date: Fri, 10 Feb 2006 15:45:00 -0000 Message-Id: From: Eli Zaretskii To: Vladimir Prus , gdb@sources.redhat.com In-reply-to: <20060210152602.GA24109@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 10 Feb 2006 10:26:02 -0500) Subject: Re: MI error messages Reply-to: Eli Zaretskii References: <20060210134700.GA21328@nevyn.them.org> <20060210152602.GA24109@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00083.txt.bz2 > Date: Fri, 10 Feb 2006 10:26:02 -0500 > From: Daniel Jacobowitz > Cc: Vladimir Prus , gdb@sources.redhat.com > > On Fri, Feb 10, 2006 at 05:22:31PM +0200, Eli Zaretskii wrote: > > > I don't think the function name adds much value in user-level error > > > messages. > > > > MI is not a user-level protocol, it's a machine-level protocol. What > > is displayed to the user as a result is another matter. > > These are just the result of calls to error (). Admittedly, many of > them are for mistakes that a GUI shouldn't be making - but some can > easily come from user input, so when you get one, I don't think you've > got much choice but to display it to the user. We are miscommunicating: what I meant was that the front end can display whatever it wants in response to such a message. In particular, it can remove the function name. But that is a separate matter; what is being discussed is what the front end should expect, not what it should display to the users. > > We should either have all or none of the MI messages state the > > function. A machine-oriented interface must be consistent, IMO. > > Then they'll have to go Fine with me.