GNU bug report logs - #16292
24.3.50; info docs now contain single straight quotes instead of `'

Previous Next

Full log

Message #81 received at 16292 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: grfz <at> gmx.de, 16292 <at> debbugs.gnu.org
Subject: Re: bug#16292: 24.3.50;
 info docs now contain single straight quotes instead of `'
Date: Thu, 02 Jan 2014 17:51:51 +0200

> Date: Wed, 01 Jan 2014 20:50:16 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
> 
> Eli Zaretskii wrote:
> > Thanks, but this should be the default, or at least should be used
> > when producing the release tarball.
> 
> No, the point is that the release tarball contains UTF-8
> info files, and that these are transformed to ASCII for installations
> that prefer ASCII info files.

But does "make install" really cut that?  How many end users on a
typical Posix platform will build and install their own Emacs?  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.

> cp-ascii's UTF8-to-ASCII transformation loses information; we can't
> ship ASCII info files in the tarball and then transform those to the
> UTF-8 originals.

That's because your Sed script goes too far, IMO: 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.

> An ASCII default would have been better years ago, but these days
> UTF-8 is the typical default encoding in GNUish distributions and
> most users will be better off if UTF-8 is the default.

I agree, when it comes to non-ASCII text.  But I see no reason for
such a strong preference when it comes to the Info markup.  I find
that a purely aesthetic consideration with no real functionality
behind it.  (It can even hurt: e.g., on one of my machines, the
Unicode quotes look pale and not so pretty at all, I guess the font
I'm using is not the best one for those characters.)

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.

  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.

  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.)  If we go this way,
     I think we should leave Unicode characters that are not Info
     markup alone, and not edit them.

  4) Use --disable-encoding switch to makeinfo, again either by
     default or given some non-default option.  This avoids the need
     for a separate Sed script, but has a complication: makeinfo 4.13,
     which I presume is still in use and which we want to support, did
     not emit the 'coding' cookie when --disable-encoding was
     specified.  OTOH, makeinfo 4.13 didn't emit Unicode quotes when
     --enable-encoding was specified.  So if we go this way, we will
     need to detect the makeinfo version and use the right switch.

  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.

If someone has other suggestions, please raise them.  Otherwise, I
guess it's decision time.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.