This is the mail archive of the
libc-locales@sourceware.org
mailing list for the GNU libc locales project.
[Bug localedata/22073] charmaps/UTF-8: wcwidth of U+00AD (soft hyphen): 0 or 1 ?
- From: "tg at mirbsd dot de" <sourceware-bugzilla at sourceware dot org>
- To: libc-locales at sourceware dot org
- Date: Thu, 14 Sep 2017 16:34:07 +0000
- Subject: [Bug localedata/22073] charmaps/UTF-8: wcwidth of U+00AD (soft hyphen): 0 or 1 ?
- Auto-submitted: auto-generated
- References: <bug-22073-716@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=22073
--- Comment #21 from Thorsten Glaser <tg at mirbsd dot de> ---
(In reply to Egmont Koblinger from comment #20)
> (In reply to Troy Korjuslommi from comment #19)
>
> > A non-SHY-aware application could easily add the U+00AD to the terminal,
> > and thus possibly cause cursor movement, and maybe even character
> > rendering, to occur.
Yes, that would be correct. The terminal is, in your terminology, *also*
a non-SHY-aware application.
> > wide characters). If SHY is wcwidth other than 0, the non-SHY-aware
> > applications will calculate the width incorrectly.
No, actually, if wcwidth is anything other than *1* they will calculate
it incorrectly, because, to a terminal, the character will always have
a constant width. (If wcwidth were 0 and an SHY-aware application were
to send U+00AD to the terminal in the place where a break DOES occur,
the terminal could NOT emit a space-using glyph otherwise.)
> There's two sides to this story: apps and terminal emulators. You seem to
> care about apps here, and forgot that altering wcwidth might have an effect
> on terminal emulators' behavior as well.
>
> If all parties respect wcwidth() then either 0 or 1 is okay. In case of 0
Indeed, both use wcwith() and thus have to agree.
> (Plus, again, let's not forget about the case of ssh'ing between different
> systems, potentially either one not even glibc-based.)
One more point in favour of letting it stay at 1 to stay compatible with
everyone else in the world including previous releases.
> to follow what gets decided in this bugreport. There's also vte's
> (gnome-terminal's) issue of using glib's method instead, but I can most
> likely change that if really needed.
Either that, or add special handling of a couple of characters to vte…
it’ll likely handle stuff like direction changes or so already if it’s
not just a dumb terminal like xterm, so there’s bound to be a correct
place for it.
--
You are receiving this mail because:
You are on the CC list for the bug.