This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: Clean up "show remote"
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 <drow@false.org>
> >
> > 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