Re: RFC: Clean up "show remote"

[Eli Zaretskii <eliz at gnu dot org>]

> 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)?

> Right now the GDB CLI is generally run either in a TTY or in some
> wrapping environment (e.g. emacs).  I don't know much about the Emacs
> case,

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.

> 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?

> 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.

> 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?

> 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 ;-)