Re: RFC: Clean up "show remote"

[Daniel Jacobowitz <drow@false.org>]

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