On Sunday, 14 July 2019 01:10:36 -03 Tom Honermann wrote:
> o Steve pondered whether all current graphical display systems are
> Unicode.
> o Tom stated that the X window system is locale based.

All the modern and relevant ones are, for all intents and purposes. Yes,
officially X is locale-based, but since font rendering has been done client-
side for the past 15 years with libraries like fontconfig, freetype, Harfbuzz
(which are Unicode-aware), virtually any text can be displayed.

That only leaves input. I remember from 15 years ago when certain applications
would allow inputting non-locale characters and some others would (Gtk ones vs
Qt ones). I distinctly remember this because I was reading Tolkien, thus
learning Old English, and I wanted to type ǽ (<dead_acute> <AltGr+a>), and I
could not in all X applications. But that just goes to show that there were
workarounds, known since at least 2003.

> o Zach suggested it would be least surprising to programmers to
> use execution encoding. That way they can just pass regular strings.

I don't think this is true in 2019 anymore. The world has sailed to UTF-8
encode source code. Like Corentin said, all major toolkits already expect that
the 8-bit char strings be UTF-8.

> o Peter stated that, On UNIX systems, UTF-8 tends to be the
> default, so things will work as is, but Windows would be
> problematic.

Indeed it is, but that is changing, as we've found out when engaging Microsoft
in discussions. They've also realised that only UTF-8 makes sense for source
code that ends up in GitHub and read by people in China, Japan, Israel, etc.

> o Zach observed that, without standard library support, converting
> text from execution encoding to UTF-8 is hard.

Indeed it is. But this is what SG-16 is supposed to solve.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel System Software Products