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

[Paul Eggert <eggert@cs.ucla.edu>]

Eli Zaretskii wrote:
> I thought the majority installs from ready-to-run packages nowadays, and
> in that case "make install" was already run by someone else, with who
> knows what configure-time options.

Yes, that's right.  Since GNU/Linux distributors typically
ship UTF-8 locales, the UTF-8 default should work.  If any
distributors want to cater to users in unibyte locales, they
can enable the option to ship ASCIIfied info files in their
packages.  I think few will, but I've been wrong before....

> it can be limited to editing only the markup and the => arrows, and
> leave the other non-ASCII characters intact.  Then there will be no
> information loss, just a different (some will say less pretty)
> display of that information.

There would still be information loss; we'll lose the
distinction between open and close quote, for example.  The
calc info file will contain "'f''2'3(x,y,z)'", for example.
Sure, a reader can eventually puzzle out which of
those apostrophes is meant to be an open single quote, close
single quote, and apostrophe (there are some of each), but
it's better if the documentation doesn't puzzle the reader.

This is the main argument for using directed quotes in the
Info files, as I see it.  Aesthetics are nice but are
secondary.

> To summarize, I see the following possible ways to solve this issue:
>
>    1) Do nothing.  This is a temporary measure at best and doesn't make
>       much sense; I mention it here only for completeness.  Sooner or
>       later we will have to do something.

Agreed.

>    2) Use "@documentencoding ISO-8859-1" in any manual that needs to
>       include non-ASCII characters.  This is what we did a year ago,
>       although a couple of manuals had utf-8 in them; they can all be
>       converted to use Latin-1.  The advantage is that this leaves the
>       markup intact; the disadvantage is that most locales will not
>       display the non-ASCII text correctly these days.

That is a fatal objection nowadays.  Another disadvantage is
that some manuals contain non-Latin-1 characters.  We could
rework them ("Latin-1-ify the manuals"), but this is heading in
the wrong direction.

>    3) Install Paul's script, which will be run at "make install" time,
>       either by default, or given a configure time option.  (We could
>       also make this  "make install" time option.)

My latest proposed patch causes this to be both a
configure-time option "configure --with-ascii-info" and a
make-time option "make INSTALL_INFO_DATA=build-aux/cp-ascii install".
So this approach is already implemented.

>       If we go this way, I think we should leave Unicode characters
>       that are not Info markup alone, and not edit them.

build-aux/cp-ascii cannot reliably distinguish Info-markup
Unicode from other Unicode, so I don't see how to implement
this precisely.  We could implement an approximation, but
why bother?  The point of cp-ascii is to not put mojibake
on unibyte users' screens, so why not fix all the mojibake
while we're at it?

>    4) Use --disable-encoding switch to makeinfo, again either by
>       default or given some non-default option.

This would lose information in the now-typical case of UTF-8 locales.

>    5) Add a feature to info.el that will set up a display table for
>       Info buffers, and use that display table to display quotes and
>       arrows on TTYs that don't support UTF-8.  Then Paul's changes to
>       use "@documentencoding utf-8" everywhere can be re-installed with
>       no additional changes.  However, unlike all the other
>       alternatives, this one solves the problem only for the Emacs Info
>       reader, and leaves the problem with the stand-alone Info reader
>       to the Texinfo maintainers.

This would be a reasonable thing to do.  It can be done
independently of (3).

Here's another option:

   6) install the original patch as-is, i.e., not bother with ASCIIfying
      the info files at all, and ask people to use UTF-8-aware software
      to read info files.  That would be simpler so I'd prefer it, but as
      I understand it Eli really dislikes this approach.  (3) is an acceptable
      compromise.

I suggest installing (3) now, as it fixes known bugs.  We
can implement (5) at our leisure.  (I say "we" but really
mean "not me", as I am no expert at display tables....)