From: Eli Zaretskii <eliz@gnu.org>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: pkoning@equallogic.com, gdb@sources.redhat.com
Subject: Re: printing wchar_t*
Date: Fri, 14 Apr 2006 17:53:00 -0000 [thread overview]
Message-ID: <uek0013sq.fsf@gnu.org> (raw)
In-Reply-To: <200604141850.08495.ghost@cs.msu.su> (message from Vladimir Prus on Fri, 14 Apr 2006 18:50:07 +0400)
> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Fri, 14 Apr 2006 18:50:07 +0400
> Cc: Paul Koning <pkoning@equallogic.com>, gdb@sources.redhat.com
>
> > You could use wchar_t arrays for that, but then not every array
> > element will be a full character, and you will not be able to access
> > individual characters by their positional index.
>
> And what? Even if wchar_t is 32 bit then element at position 'i' can be
> combining character modifying another character, and be of little use itself.
You are introducing into the argument yet another face of a character:
how it is displayed. It's true that some characters, when they are
adjacent to each other, are displayed in some special way (the ff
ligature is one simple example of that), but that is something for the
rendering engine to take care of, it has nothing to do with the
string's content. As far as any software, except the rendering
engine, is concerned, the combining character is, in fact, part of the
string. For example, if the user wants to search for such a
character, the program must find it.
So, for the purposes of processing the wchar_t strings, it is very
important to know whether they are fixed-size wide characters or
variable-size encoding. If you just copy the string verbatim to and
fro, then it doesn't matter, but for anything more complex the
difference is very large.
> > If we want to support wchar_t arrays that store UTF-16, we will need
> > to add a feature to GDB to convert UTF-16 to the full UCS-4
> > codepoints, and output those.
>
> That's what I mentioned in a reply to Jim -- since the current string printing
> code operated "one wchar_t at a time", it's not suitable for outputing UTF-16
> encoded wchar_t values to the user.
I don't understand: if the wchar_t array holds a UTF-16 encoding, then
when you receive the entire string, you have a UTF-16 encoding of what
you want to display, and you yourself said that displaying a UTF-16
encoded string is easy for you. So where is the problem? is that only
that you cannot know the length of the UTF-16 encoded string? or is
there something else missing?
> > Alternatively, the FE will have to
> > support display of UTF-16 encoded characters.
>
> Speaking about FE, handling UTF-16 is trivial
Maybe in your environment and windowing system, but not in all cases,
AFAIK.
next prev parent reply other threads:[~2006-04-14 17:10 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-13 17:07 Vladimir Prus
2006-04-13 17:25 ` Eli Zaretskii
2006-04-14 7:29 ` Vladimir Prus
2006-04-14 8:47 ` Eli Zaretskii
2006-04-14 12:47 ` Vladimir Prus
2006-04-14 13:05 ` Eli Zaretskii
2006-04-14 13:06 ` Vladimir Prus
2006-04-14 13:15 ` Robert Dewar
2006-04-14 13:17 ` Daniel Jacobowitz
2006-04-14 13:59 ` Robert Dewar
2006-04-14 14:37 ` Eli Zaretskii
2006-04-14 14:08 ` Paul Koning
2006-04-14 14:47 ` Eli Zaretskii
2006-04-14 15:00 ` Vladimir Prus
2006-04-14 17:53 ` Eli Zaretskii [this message]
2006-04-17 7:05 ` Vladimir Prus
2006-04-17 8:35 ` Eli Zaretskii
2006-04-13 18:06 ` Jim Blandy
2006-04-13 21:18 ` Eli Zaretskii
2006-04-14 6:02 ` Jim Blandy
2006-04-14 8:43 ` Eli Zaretskii
2006-04-14 7:58 ` Vladimir Prus
2006-04-14 8:07 ` Jim Blandy
2006-04-14 8:30 ` Vladimir Prus
2006-04-14 8:57 ` Eli Zaretskii
2006-04-14 12:52 ` Vladimir Prus
2006-04-14 13:07 ` Daniel Jacobowitz
2006-04-14 14:23 ` Eli Zaretskii
2006-04-14 14:29 ` Daniel Jacobowitz
2006-04-14 14:53 ` Eli Zaretskii
2006-04-14 17:10 ` Daniel Jacobowitz
2006-04-14 17:55 ` Jim Blandy
2006-04-14 18:27 ` Eli Zaretskii
2006-04-14 18:30 ` Jim Blandy
2006-04-14 19:19 ` Eli Zaretskii
2006-04-14 14:16 ` Eli Zaretskii
2006-04-14 14:50 ` Vladimir Prus
2006-04-14 17:18 ` Eli Zaretskii
2006-04-14 18:03 ` Jim Blandy
2006-04-14 19:16 ` Eli Zaretskii
2006-04-14 19:22 ` Jim Blandy
2006-04-14 22:18 ` Daniel Jacobowitz
2006-04-16 11:39 ` Jim Blandy
2006-04-16 15:07 ` Eli Zaretskii
2006-04-15 7:14 ` Eli Zaretskii
2006-04-17 7:16 ` Vladimir Prus
2006-04-17 8:58 ` Eli Zaretskii
2006-04-17 10:35 ` Vladimir Prus
2006-04-17 12:26 ` Eli Zaretskii
2006-04-17 13:56 ` Vladimir Prus
2006-04-18 5:31 ` Eli Zaretskii
2006-04-14 19:53 ` Mark Kettenis
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=uek0013sq.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb@sources.redhat.com \
--cc=ghost@cs.msu.su \
--cc=pkoning@equallogic.com \
/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