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

[Eli Zaretskii]

> Date: Tue, 31 Dec 2013 23:03:07 -0800
> From: Paul Eggert <address@hidden>
> CC: address@hidden
> 
> Eli Zaretskii wrote:
> 
> >> We changed it in the first place because of vociferous complaints
> >> about getting ASCII quotes even with @documentencoding UTF-8.
> >
> > Well, you now have vociferous complaints to the contrary.
> 
> We have one complaint, from you.

Isn't that enough?

> In contrast, we have multiple complaints from users who prefer the
> UTF-8 approach that's already in texinfo.

If you mean people who want Unicode quotes, then those users can
regenerate the Info files for themselves.  What bothers me are the
Info files that get into the release tarball -- these should be
readable by everyone.

> Latin-1 locales are becoming rarer in practice,

I didn't argue for Latin-1, so I'm not sure where does this come
from.  Maybe from another argument ;-)

> > in an otherwise English manual, having
> > Unicode quotes makes the manual unreadable.
> 
> It's readable.

No, it's not.  Let me show it again, since this forum didn't see it
yet.  This is from a typical node in the ELisp manual:

     The usual read syntax for alphanumeric characters is a question mark
  followed by the character; thus, \u2018?A\u2019 for the character 
\u2018A\u2019, \u2018?B\u2019 for
  the character \u2018B\u2019, and \u2018?a\u2019 for the character 
\u2018a\u2019.

     For example:

       ?Q => 81     ?q => 113

     You can use the same syntax for punctuation characters, but it is
  often a good idea to add a \u2018\\u2019 so that the Emacs commands for 
editing
  Lisp code don\u2019t get confused.  For example, \u2018?\(\u2019 is the way 
to write
  the open-paren character.  If the character is \u2018\\u2019, you _must_ use a
  second \u2018\\u2019 to quote it: \u2018?\\\u2019.

     You can express the characters control-g, backspace, tab, newline,
  vertical tab, formfeed, space, return, del, and escape as \u2018?\a\u2019, 
\u2018?\b\u2019,
  \u2018?\t\u2019, \u2018?\n\u2019, \u2018?\v\u2019, \u2018?\f\u2019, 
\u2018?\s\u2019, \u2018?\r\u2019, \u2018?\d\u2019, and \u2018?\e\u2019,
  respectively.  (\u2018?\s\u2019 followed by a dash has a different meaning--it
  applies the \u201csuper\u201d modifier to the following character.)  Thus,

       ?\a \u21D2 7                 ; control-g, \u2018C-g\u2019
       ?\b \u21D2 8                 ; backspace, <BS>, \u2018C-h\u2019
       ?\t \u21D2 9                 ; tab, <TAB>, \u2018C-i\u2019
       ?\n \u21D2 10                ; newline, \u2018C-j\u2019
       ?\v \u21D2 11                ; vertical tab, \u2018C-k\u2019
       ?\f \u21D2 12                ; formfeed character, \u2018C-l\u2019
       ?\r \u21D2 13                ; carriage return, <RET>, \u2018C-m\u2019
       ?\e \u21D2 27                ; escape character, <ESC>, \u2018C-[\u2019
       ?\s \u21D2 32                ; space character, <SPC>
       ?\\ \u21D2 92                ; backslash character, \u2018\\u2019
       ?\d \u21D2 127               ; delete character, <DEL>

     These sequences which start with backslash are also known as \u201Cescape
  sequences\u201D, because backslash plays the role of an \u201Cescape 
character\u201D;
  this terminology has nothing to do with the character <ESC>.  \u2018\s\u2019 
is
  meant for use in character constants; in string constants, just write
  the space.

The above is in the Emacs Info reader.  In the stand-alone reader, it
is even worse.

> 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),
and even if it is, asking people to switch their locale just to read
the manual is not a nice thing.  It's the tail wagging the dog.