Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: gdb-patches@sourceware.org
Subject: Re: RFC: Clean up "show remote"
Date: Tue, 24 Jan 2006 22:10:00 -0000	[thread overview]
Message-ID: <ubqy1ffaw.fsf@gnu.org> (raw)
In-Reply-To: <20060124214858.GA27783@nevyn.them.org> (message from Daniel 	Jacobowitz on Tue, 24 Jan 2006 16:48:58 -0500)

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


  reply	other threads:[~2006-01-24 22:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-22 20:18 Daniel Jacobowitz
2006-01-23  4:38 ` Eli Zaretskii
2006-01-23  5:15   ` Daniel Jacobowitz
2006-01-23 22:44     ` Eli Zaretskii
2006-01-24 16:53       ` Daniel Jacobowitz
2006-01-24 21:24         ` Eli Zaretskii
2006-01-24 21:28         ` Eli Zaretskii
2006-01-24 21:49           ` Daniel Jacobowitz
2006-01-24 22:10             ` Eli Zaretskii [this message]
2006-01-24 22:18               ` Daniel Jacobowitz
2006-02-02  2:07     ` Daniel Jacobowitz
2006-01-23 23:01 ` Jim Blandy
2006-01-23 23:24   ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ubqy1ffaw.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox