This is the mail archive of the libc-locales@sourceware.org mailing list for the GNU libc locales project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug localedata/22073] charmaps/UTF-8: wcwidth of U+00AD (soft hyphen): 0 or 1 ?


https://sourceware.org/bugzilla/show_bug.cgi?id=22073

--- Comment #20 from Egmont Koblinger <egmont at gmail dot com> ---
(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.

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 the
terminal emulator will not print anything nor advance the cursor, in accordance
with what the app expects. In case of 1 the outcome again will be correct.

The story is about to foresee the impacts of apps as well as terminal emulators
(and their combinations) that use hardcoded values rather than wcwidth. For
example, I don't know if xterm always uses its built-in table, or only in
certain cases; nor whether its author is open to adjust the table 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.

(Plus, again, let's not forget about the case of ssh'ing between different
systems, potentially either one not even glibc-based.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]