[Top][All Lists]

[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

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.

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

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....)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]