From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#16292: 24.3.50; info docs now contain single straight quotes instead of `' Date: Thu, 02 Jan 2014 11:28:17 -0800 Organization: UCLA Computer Science Department Message-ID: <52C5BDD1.2050009@cs.ucla.edu> References: <20131229220810.GF7972@boo.workgroup> <52C0E734.4090403@cs.ucla.edu> <83sita1cbw.fsf@gnu.org> <52C1C456.2080004@cs.ucla.edu> <83fvpa16kh.fsf@gnu.org> <52C25D07.80808@cs.ucla.edu> <8338l91l2t.fsf@gnu.org> <52C4C95C.2010905@cs.ucla.edu> <837gajyrq1.fsf@gnu.org> <52C4F008.5060003@cs.ucla.edu> <83zjnextyg.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1388690956 19108 80.91.229.3 (2 Jan 2014 19:29:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Jan 2014 19:29:16 +0000 (UTC) Cc: grfz@gmx.de, 16292@debbugs.gnu.org To: Eli Zaretskii , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jan 02 20:29:21 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VynxI-0006sO-GL for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 Jan 2014 20:29:20 +0100 Original-Received: from localhost ([::1]:46723 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VynxI-00037L-3G for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 Jan 2014 14:29:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36104) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vynx8-0002zh-DE for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2014 14:29:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vynx0-0005WQ-8E for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2014 14:29:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44383) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vynx0-0005WM-4d for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2014 14:29:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Vynwz-00055b-IN for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2014 14:29:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Jan 2014 19:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16292-submit@debbugs.gnu.org id=B16292.138869091819517 (code B ref 16292); Thu, 02 Jan 2014 19:29:01 +0000 Original-Received: (at 16292) by debbugs.gnu.org; 2 Jan 2014 19:28:38 +0000 Original-Received: from localhost ([127.0.0.1]:58399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VynwX-00054Z-0D for submit@debbugs.gnu.org; Thu, 02 Jan 2014 14:28:37 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:57197) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VynwP-00054J-OL for 16292@debbugs.gnu.org; Thu, 02 Jan 2014 14:28:26 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id AE13139E80F8; Thu, 2 Jan 2014 11:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfIgJndmiU4C; Thu, 2 Jan 2014 11:28:24 -0800 (PST) Original-Received: from [192.168.1.9] (pool-108-0-233-62.lsanca.fios.verizon.net [108.0.233.62]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 0882E39E8008; Thu, 2 Jan 2014 11:28:24 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <83zjnextyg.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:82837 Archived-At: 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....)