From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11343 invoked by alias); 24 Jan 2006 16:53:31 -0000 Received: (qmail 11335 invoked by uid 22791); 24 Jan 2006 16:53:30 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 24 Jan 2006 16:53:28 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F1RQ6-0005AB-3r for gdb-patches@sourceware.org; Tue, 24 Jan 2006 11:53:26 -0500 Date: Tue, 24 Jan 2006 16:53:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Subject: Re: RFC: Clean up "show remote" Message-ID: <20060124165326.GA19716@nevyn.them.org> Mail-Followup-To: gdb-patches@sourceware.org References: <20060122201759.GA28863@nevyn.them.org> <20060123051544.GA5009@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00359.txt.bz2 On Tue, Jan 24, 2006 at 12:44:28AM +0200, Eli Zaretskii wrote: > > Date: Mon, 23 Jan 2006 00:15:44 -0500 > > From: Daniel Jacobowitz > > > > > With your change, the part in parentheses will not be displayed, so > > > how would the user know that Z0 is a packet that sets software > > > breakpoints? > > > > Instead, you'll get something that looks like the current output of > > "show print": > > > > software-breakpoint-packet: Support for the `Z0' packet is auto-detected, currently unknown > > Right, I didn't catch the part before the colon, since it's in another > place in the code. > > But doesn't the above looks backwards, English-wise? we first announce > the full packet name, and then say that support for its short alias is > . The "foo: Bar" syntax is usually reserved for messages > that come from `foo', which is not really the case here. Well, it doesn't look at all unnatural to me. It would if there were only one of them, but there's a whole list. To recap (from memory, forgive typos): (gdb) show remote software-breakpoint-backet Support for the `Z0' packet is auto-detected, currently unknown (gdb) show remote software-breakpoint-packet: Support for the `Z0' packet is auto-detected, currently unknown hardware-breakpoint-packet: Support for the `Z1' packet is auto-detected, currently unknown [more...] > > I'm trying to cut down on how badly this wraps, since we can't > > word-wrap in translated messages (is there any way to do that? > > The only good way is to break it into two separate messages and mark > them in i18n comments as belonging to the same phrase. Translators > will then break the translated message as appropriate for their > language (or even produce a single line, by translating the second > part as an empty string). > > > GCC seems to wrap using spaces even in i18n output; maybe we > > could do the same, if I am interpreting that right?). > > If that's what GCC does, GCC is not doing TRT: wrapping on spaces > works for Latin and other similar languages, but can be dead wrong in > other scripts. This would be a terrible shame. I asked for opinions from a couple of GCC developers, and Paolo Bonzini suggested: > if a translator is anal about where to break, he should use non-breaking spaces > (such as Unicode 160) and those answer false for iswspace > iow, doing mbstowcs, breaking at iswspace, and converting back, should work. > but it's sort of a mess > ask eli if that's correct. maybe it's not. Is that right? If not, is there some forum where I could get a definitive answer? No one's ever complained about the GCC wrapping (well, people have complained about a related problem in the English wrapping output, but not about bad wrapping in translations as far as I can see); and it's very convenient. I'd love to be able to make GDB word-break output. Right now we just write overlength messages to the screen. I don't see how that can be an improvement over breaking them at whitespace instead of at the margins, but maybe I'm missing something? -- Daniel Jacobowitz CodeSourcery