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

[egmont at gmail dot com]

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

--- Comment #22 from Egmont Koblinger <egmont at gmail dot com> ---
(In reply to Thorsten Glaser from comment #21)

> Yes, that would be correct. The terminal is, in your terminology, *also*
> a non-SHY-aware application.

I'd rather not define this concept for terminals. They cannot make a choice in
the sense client apps can.

Also for conciseness I'd reserve the word "app" or "application" for the client
app that's running inside the terminal emulator, and not the terminal emulator
itself in this discussion.

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

Nope. SHY-aware apps by definition never send SHY to the terminal, they either
send a regular hyphen U+2D or nothing at all, that's what makes them SHY-aware.
(Especially since in several fonts the glyph of SHY is empty, it looks like a
space.) If an app ever sends a SHY to the terminal emulator, it is SHY-unaware.

Hence for SHY-aware apps, wcwidth() of SHY is irrelevant.

For SHY-unaware ones it's important that what the application thinks will
happen matches with what really happens in the terminal emulator. Both the
application and the terminal emulator may or may not rely on wcwidth(), or the
app may even rely on wcwidth() of a remote system.

> One more point in favour of letting it stay at 1 to stay compatible with
> everyone else in the world including previous releases.

I'm not arguing against 1 at all. In fact, my guts feeling tell me to go with 1
rather than 0. I just wouldn't want 0 being ditched with invalid arguments.

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

There's no BiDi in VTE, anyway, I wouldn't want to pollute this bugreport with
this.

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