bug#16292: 24.3.50; info docs now contain single straight quotes instead of `'

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 29 Dec 2013 19:23:32 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> Apparently the problem is that some of Emacs's .texi files
> contain @documentencoding directives and generate curly quotes,
> while others don't and generate straight quotes.  It's better to
> be consistent, and curly quotes seem more useful, so I installed
> a patch to do that as trunk bzr 115807.  I assume this fixes the
> bug and so am closing this bug report; if it's not fixed please
> let me know.

Very sorry, but I reverted that commit: it screws up anyone who wants
to read the docs on a text terminal that doesn't support UTF-8.  At
best, you see something like

  Hash notation cannot be read at all, so the Lisp reader signals the
  error \u2018invalid-read-syntax\u2019 whenever it encounters \u2018#<\u2019.

At worst, you see this kind of gibberish:

     In most cases, an objectΓאשs printed representation is also a read
  syntax for the object.  However, some types have no read syntax, since
  it does not make sense to enter objects of these types as constants in a
  Lisp program.  These objects are printed in "hash notation", which
  consists of the characters Γאר#<Γאש, a descriptive string (typically the
  type name followed by the name of the object), and a closing Γאר>Γאש.  For
  example:

       (current-buffer)
	    Γחע #<buffer objects.texi>

I'm sorry, we cannot possibly distribute documentation that looks like
this in some locales.  For Emacs Info reader, we could perhaps fix
that by using a display table, but there's no such solution available
for the stand-alone Info reader that is part of Texinfo.

This change should have never been committed without a discussion,
certainly not during a feature freeze.

Of course, before this commit, we already had such a problem in
several files, which started using UTF-8 encoding since the last
March.  But that, too, was never discussed AFAIR, and its effect on
@code, @samp, etc. markup, as well as on ``..'' quoted text, was never
mentioned.  (These effects are barely documented in the Texinfo
manual, so it was easy to miss the meaning of those changes.  I
submitted a bug report to Texinfo maintainers about this documentation
deficiency.)

So now we are left with a few files that still specify UTF-8, and
still screw up text-mode Info readers in some locales.  Those files
were using Latin-1 before the changes in March 2013, which allowed us
to display a few non-ASCII words in Latin locales, but still have the
quotes and markup legible in all locales.

So, unless someone has a better idea, I will in a day or two revert
those files back to Latin-1.  This will not be optimal, since names of
some people (I counted 4) mentioned in at least one of those files
cannot be encoded in Latin-1, and so we will need to use the ASCII
imitation offered by Texinfo (as we did before the switch to UTF-8).
But that is IMO a lesser evil than denying legible manuals to various
non-UTF locales.

As for the OP's report: I agree with Glenn that the ship with `..'
quoting in Info sailed a long time ago.  I was against that change in
Texinfo (as was Karl Berry, one of the main Texinfo developers), but
this was voted down, so there's no sense in arguing about that.  If
info+ needs to parse the quoting to highlight marked-up text, it will
have to adapt, sorry.  (Or lobby on the Texinfo list for reverting to
previous behavior.)

I'm going to reopen the bug.