[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: |
Paul Eggert |
Subject: |
bug#16292: 24.3.50; info docs now contain single straight quotes instead of `' |
Date: |
Thu, 02 Jan 2014 11:28:17 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 |
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....)
- 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, 2014/01/02
- bug#16292: 24.3.50; info docs now contain single straight quotes instead of `',
Paul Eggert <=
- 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
- bug#16292: 24.3.50; info docs now contain single straight quotes instead of `', Drew Adams, 2014/01/03