Re: Standalone 'info' should recode into display's encoding

[Paul Eggert]

Eli Zaretskii wrote:

> the Info files that get into the release tarball --
> these should be readable by everyone.

The release tarball is not the central issue;  What matters
is what the user sees.  Today I proposed an Emacs
patch in <http://bugs.gnu.org/16292#63> that would cause Emacs
'make install-info' to (as a configure-time option)
install ASCIIfied versions of the info files.
This  should address the problem even if 'info' is not adjusted
to work better in unibyte locales.

> > But the fix is simple and readily available: use a UTF-8 locale.
>
> It is not readily available (the UTF-8 locale might not be installed),

This objection had force decades ago, when this situation was common.
But it's uncommon now.  All standard distributions come with
UTF-8 locales and support for UTF-8 encoding.  UTF-8 is
typically the default in GNUish installations,
even older ones such as fencepost.gnu.org.  And even the oldest,
gnarliest POSIXish installation I have access to (a
Solaris 10 host, dating from 2005) has UTF-8 installed.

> asking people to switch their locale

This shouldn't happen often.  Unibyte locales are not that
common among Emacs users any more, except for experts who use
the C locale for efficiency -- and they know what they're doing.

> > > Well, you now have vociferous complaints to the contrary.
> > We have one complaint, from you.
>
> Isn't that enough?

You are an expert, and can easily fix the problem yourself
by using an appropriate locale.  It's questionable whether
there is a significant non-expert user population with this
problem.  Nowadays users typically have different concerns,
such as the original report in Bug #16292.

> > It's readable.
>
> No, it's not.  Let me show it again,

It's readable, in the sense that it doesn't significantly
affect the reader's ability to understand the presented
material.  The mojibake *is* really ugly, admittedly.
Anyway, this point should be moot for Emacs, given
the patch in <http://bugs.gnu.org/16292#63>.