From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20005 invoked by alias); 24 Jan 2006 22:18:45 -0000 Received: (qmail 19992 invoked by uid 22791); 24 Jan 2006 22:18:43 -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 22:18:40 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F1WUo-0007Yb-Gz for gdb-patches@sourceware.org; Tue, 24 Jan 2006 17:18:38 -0500 Date: Tue, 24 Jan 2006 22:18:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Subject: Re: RFC: Clean up "show remote" Message-ID: <20060124221838.GD27626@nevyn.them.org> Mail-Followup-To: gdb-patches@sourceware.org References: <20060122201759.GA28863@nevyn.them.org> <20060123051544.GA5009@nevyn.them.org> <20060124165326.GA19716@nevyn.them.org> <20060124214858.GA27783@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/msg00387.txt.bz2 On Wed, Jan 25, 2006 at 12:10:15AM +0200, Eli Zaretskii wrote: > > Date: Tue, 24 Jan 2006 16:48:58 -0500 > > From: Daniel Jacobowitz > > > > Asking the translator do it defeats my goal - which is to adapt to the > > user's terminal width, automatically. > > That's true, but does this work well with non-Latin scripts > (i.e. those where the characters' widths are not equal)? Yes, it does. We can use the POSIX wide character interface, which includes wcwidth() for this purpose. Of course, when you're in a non-fixed-width font this is going to break down. But terminals for languages with wide characters still seem to use fixed-width columns, in my experience. (That experience is somewhat limited, but I have experimented with Chinese and Japanese terminal emulators for ncurses bug reports a couple of times). > The Emacs case is not interesting: Emacs disables the wrapping (both > horizontal and vertical) and wraps itself, according to its rules and > user's preferences. Great. > > but at least on a TTY, when we encounter the terminal's physical > > margins we wrap - always. No matter where we are within a word. > > You mean, the TTY wraps, yes? Right, that's what I meant - GDB doesn't even know where. > > How is wrapping after spaces, as suggested by the Unicode TR but > > without the remaining complexity of the TR, inferior to that? > > It might not work at all, when there are not enough spaces in the > line. Which is not worse than what we have now, but at least now we > don't claim we have this feature. Well, that's true. At this point I think we'd have a pretty convincing reason to implement the rest of the TR :-) > > We'd check widths and space characters on the results of gettext, of > > course, using appropriate wide character routines. > > Will this work on terminal emulators in a graphical environment, such > as xterm? Won't we need some knowledge about the font? It'll still work - Xterm generally uses a fixed width font, even for scripts with wide characters. In fact this is the case I'm most interested in (I use GDB inside "screen" inside an xterm or rxvt, 99% of the time). > > There are probably some cases where this would lead to oddly placed > > line breaks. I'm hypothesizing that there would be fewer oddly placed > > line breaks even in the affected scripts than there are today. > > Maybe, I don't know. > > Anyway, since we don't yet support i18n, perhaps we shouldn't worry > now about implementing Unicode line-breaking, or even subset thereof. > There are more important things to do, I think. (Although, having > once written a very unorthodox implementation of the Unicode > Bidirectional Algorithm--see UAX#9 on the Unicode site--I can > easily understand how tempting can it be to sit down and implement a > significant subset of the line-breaking algorithm ;-) I don't want to add new features that are going to be a problem when we do support i18n - no one's moving us further toward that goal at the moment, but I don't want us moving gratuituously away from it, either :-) I speculate that the TR offers a sufficient way forward, were we to start supporting i18n, that I don't need to feel guilty implementing wrapping based on gettext output. I'm not going to do it tonight, but maybe I'll do it sometime soon - it would really make me a happier user of GDB. -- Daniel Jacobowitz CodeSourcery