Re: [Emacs-diffs] master 9ce1d38: Use curved quotes in core elisp diagnostics

[Eli Zaretskii]

> From: Yuri Khan <address@hidden>
> Date: Wed, 19 Aug 2015 10:45:32 +0600
> Cc: Alan Mackenzie <address@hidden>, Paul Eggert <address@hidden>, Brief 
> Busters <address@hidden>, 
>       Emacs developers <address@hidden>
> 
> >> I used to use Windows, including the Windows console, as my primary
> >> environment. It displays most of the European part of Unicode
> >> allright, once you configure it to use a TrueType or OpenType font.
> >
> > Europe is but a small part of the world, and the fonts available for
> > that on the Windows console are ugly and hard to read.
> 
> The Windows console has a two-stage mechanism for configuring the font.
> 
> First, the registry specifies a subset of fonts which can be used in
> the console. Initially this subset only contains Lucida Console or
> Courier New. As far as I can tell, Far East localizations add a
> CJK-enabled font.

This is year 2015.  We are way past "localization" phase of the 1990s,
when certain features existed only in certain locales.  Features that
require installation of extra language packs, like Far-Eastern
localizations, and aren't available otherwise, cannot be relied upon.
They don't exist for all practical purposes.  You cannot tell your
users to install those localizations, because most of them won't.  The
result is that displaying CJK text on a Windows console only works in
CJK locales, and similarly with other scripts outside of Europe.  That
flies in the face of any decent multilingual environment such as
Emacs.

We need these features working out of the box, on any end-user's
machine.  Until then, they don't exist, and therefore Emacs in its
console mode cannot provide a decent multilingual environment on
Windows.

> I used Andale Mono and subsequently Liberation Mono with great success.

Good for you.  But this doesn't solve the problem for others.  Very
few people will invest a significant amount of their time into
tinkering with their systems.  A solution that relies on that will not
fly.

> >> Some applications (notably, ports of Unix utilities) have problems
> >> displaying Unicode on the Windows console. That is a bug in those
> >> applications.
> >
> > LOL.  I have yet to see a native Windows port of a significant Unix
> > utility that doesn't have that "bug".
> 
> Ubiquity of a bug does not imply that it can or should go unfixed.

But it does say something about the scale of the problem.  It's not
like a "non-buggy" port exists somewhere and you can tell people to
install it instead of the buggy one they have.  Fixing this is hard,
because Windows doesn't yet fully support the UTF-8 codepage, so any
program that uses 'char *' for text strings needs radical changes to
fix this "bug".  It's a small wonder that there are almost no programs
that have this fixed.

Your misrepresentations of these problems makes a disservice to people
who read them.