Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Philip Guenther (guenthergmail.com)
Date: Thu Aug 05 2010 - 13:33:23 CDT
On Thu, Aug 5, 2010 at 5:49 AM, Matthew Szudzik <mszudzikandrew.cmu.edu>
> But it's even worse, because unicode also violates the principle
> (established by Alan Turing in 1936) that any two characters should be
> humanly distinguishable "at a glance".
> This has led to the invention of
> punycode for translating unicode strings into humanly distinguishable
> ASCII strings. But then why did we switch from ASCII to unicode in the
> first place?
Umm, punycode wasn't developed because of problems with
distinguishability. Indeed, it does nothing to solve those, so I'm
not sure why you would suggest that. punycode exists to encode
unicode across a transport that is, in effect, in base36, with various
requirements on interpretation.
> It's my opinion that unicode shouldn't have a place in the Unix
> terminal. You might want your GUI to display unicode characters, but
> when I'm working from a terminal, I want to see the data as closely as
> possible to the way that the computer "sees" the data.
So you want to see '41' instead of the letter 'A'? That's "how the
computer sees the data"...
> For example, I don't want nvi to display unicode characters, I want to see
> individual 8-bit byte that composes the character. I don't want unicode
> on the command line.
Those that are wedded to plain ASCII can continue to have that
experience by using LC_ALL=C. Oops, never mind, OpenBSD hasn't
actually implemented "plain ASCII only" for years.