[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16292: 24.3.50; info docs now contain single straight quotes instead
From: |
Eli Zaretskii |
Subject: |
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@cs.ucla.edu>
> CC: 16292@debbugs.gnu.org, grfz@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.
- bug#16292: 24.3.50; info docs now contain single straight quotes instead of `', Paul Eggert, 2014/01/01
- bug#16292: 24.3.50; info docs now contain single straight quotes instead of `', Eli Zaretskii, 2014/01/01
- bug#16292: 24.3.50; info docs now contain single straight quotes instead of `', Paul Eggert, 2014/01/01
- bug#16292: 24.3.50; info docs now contain single straight quotes instead of `',
Eli Zaretskii <=
- bug#16292: 24.3.50; info docs now contain single straight quotes instead of `', Paul Eggert, 2014/01/02
- bug#16292: 24.3.50; info docs now contain single straight quotes instead of `', Eli Zaretskii, 2014/01/02
- bug#16292: 24.3.50; info docs now contain single straight quotes instead of `', Paul Eggert, 2014/01/02
- bug#16292: 24.3.50; info docs now contain single straight quotes instead of `', Eli Zaretskii, 2014/01/03
- bug#16292: 24.3.50; info docs now contain single straight quotes instead of `', Paul Eggert, 2014/01/03
- bug#16292: 24.3.50; info docs now contain single straight quotes instead of `', Eli Zaretskii, 2014/01/03
- bug#16292: 24.3.50; info docs now contain single straight quotes instead of `', Paul Eggert, 2014/01/03
- bug#16292: 24.3.50; info docs now contain single straight quotes instead of `', Eli Zaretskii, 2014/01/03
- bug#16292: 24.3.50; info docs now contain single straight quotes instead of `', Stefan Monnier, 2014/01/03
- bug#16292: 24.3.50; info docs now contain single straight quotes instead of `', Paul Eggert, 2014/01/03