From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#16292: 24.3.50; info docs now contain single straight quotes instead of `' Date: Fri, 2 May 2014 13:53:45 -0700 (PDT) Message-ID: References: <<83zjnextyg.fsf@gnu.org>> <<52C5BDD1.2050009@cs.ucla.edu> <83ppoaxfu6.fsf@gnu.org>> <<52C607DA.3090009@cs.ucla.edu> <83fvp5xzk0.fsf@gnu.org>> <<52C6F2C5.10505@cs.ucla.edu> <83mwjcx1i9.fsf@gnu.org>> < <52C750C4.6040006@cs.ucla.edu> <8338l4w5pj.fsf@gnu.org>> < <83ha9jv5lh.fsf@gnu.org>> < <838uuvum9n.fsf@gnu.org>> < <8338l2v1tn.fsf@gnu.org>> <<52C9BA68.7050703@cs.ucla.edu> <83fvp2tcqx.fsf@gnu.org>> <<52C9BCBF.7050904@cs.ucla.edu> <83eh4mtc52.fsf@gnu.org>> <<52C9E53D.8070106@cs.ucla.edu> <838uutu5mu.fsf@gnu.org>> <<52CA3FB9.30509@cs.ucla.edu> <834n5ht7bz.fsf@gnu.org>> <<52CB5517.4030502@cs.ucla.edu>> <<83lhyssawf.fsf@gnu.org>> <5363ECDA.8050305@cs.ucla.edu> <57f18f83-5ac5-4bde-8268-ba89f159c676@default> <536401DB.7080606@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1399064071 21329 80.91.229.3 (2 May 2014 20:54:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 2 May 2014 20:54:31 +0000 (UTC) Cc: grfz@gmx.de, 16292@debbugs.gnu.org To: Paul Eggert , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 02 22:54:24 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 1WgKTN-0007xl-3H for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 May 2014 22:54:21 +0200 Original-Received: from localhost ([::1]:46268 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WgKTM-0001Kl-MC for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 May 2014 16:54:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WgKTC-0001KU-2D for bug-gnu-emacs@gnu.org; Fri, 02 May 2014 16:54:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WgKT5-00010b-7F for bug-gnu-emacs@gnu.org; Fri, 02 May 2014 16:54:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59662) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WgKT5-00010T-3K for bug-gnu-emacs@gnu.org; Fri, 02 May 2014 16:54:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WgKT4-0001X0-BK for bug-gnu-emacs@gnu.org; Fri, 02 May 2014 16:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 02 May 2014 20:54:02 +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.13990640395878 (code B ref 16292); Fri, 02 May 2014 20:54:02 +0000 Original-Received: (at 16292) by debbugs.gnu.org; 2 May 2014 20:53:59 +0000 Original-Received: from localhost ([127.0.0.1]:48780 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WgKT0-0001Wj-QP for submit@debbugs.gnu.org; Fri, 02 May 2014 16:53:59 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:28189) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WgKSy-0001WP-5T for 16292@debbugs.gnu.org; Fri, 02 May 2014 16:53:56 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s42Krnpe016993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 May 2014 20:53:49 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s42KrlF0018529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2014 20:53:49 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s42KrjSB018482; Fri, 2 May 2014 20:53:46 GMT In-Reply-To: <536401DB.7080606@cs.ucla.edu> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] 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:88547 Archived-At: > >> Perhaps your info+.el user could investigate why makeinfo is > >> misbehaving for them, > > Can you suggest how? >=20 > Run 'makeinfo' on the attached file t.texi and look at the quoting in > the output file t.info. It should use ASCII accent-grave and apostrophe > with old texinfo, and Unicode curly single quotes with new texinfo. > Similarly, the double quotes should use ASCII undirected double-quote > (both times) with old texinfo, and Unicode curly double quotes with new > texinfo. OK, I just passed that information along to him. FWIW, I have received this info from him: I built from source with makinfo 5.2. However, makeinfo 5.2 works fine for Emacs pretest (emacs 24.3.90), but not for Emacs trunk (24.4.50): bzr branch bzr://bzr.savannah.gnu.org/emacs/trunk Here are the steps to build: - ./configure --with-x-toolkit=3Dgtk - make - sudo make install What does old vs new texinfo refer to? Did you perhaps mean old vs new makeinfo? If not, how does he tell whether he has "old" or "new" Texinfo? > > I would still want Info+ to be able to easily test, using Lisp, which > > is being used in the current Info buffer: `...' or '...'. >=20 > Info files should never use the latter in Emacs 24.4, so this shouldn't > be a problem. > > Down the road there may be a problem, as we really need to accommodate > new Texinfo. It has been suggested that we change the Emacs build > procedure to transliterate the output of new Texinfo so that by default > it quotes 'like this' instead of =E2=80=98like this=E2=80=99. I think thi= s would be a > mistake, and your recent bug report gives another argument against it. Is the problem just for `...' vs '...' or =E2=80=98...=E2=80=99? What abou= t Lisp (and other) code, where we use ", ', and `, and none of those should be changed to a curly version of the same? A Lisp string, for instance, must be enclosed in straight double-quote chars, the same char at each end. It would be madness if such chars were being automatically "improved" everywhere willy nilly to become curly versions. > For your planning purposes, here is a list of non-ASCII characters that > are generated by new Texinfo when applied to the Emacs documentation as > of January or so. You might want to check that info+.el handles these > characters, as some users will run into them either because they built > the manuals themselves with new Texinfo, or because they're reading > manuals generated by other GNU projects. I think Emacs is the only > holdout that still insists on old Texinfo. >=20 > ' ' (i.e., NO-BREAK SPACE, U+00A0) > '=E7=9C=9F' (i.e., Han character 'real, actual, true, genuine', U+771F) >=20 > =C2=A4 =C2=A9 =C2=AC =C2=BB =C3=80 =C3=85 =C3=9F =C3=A0 =C3=A1 =C3=A4 =C3= =A5 =C3=A7 =C3=A8 =C3=A9 =C3=AA =C3=AC =C3=AD =C3=AF =C3=B2 =C3=B3 =C3=B6 = =C3=B8 =C3=BC =C4=87 =C4=8D =C5=82 =C5=84 =C5=91 =C5=A0 =C5=A1 =E2=80=93 = =E2=80=94 =E2=80=98 =E2=80=99 =E2=80=9C =E2=80=9D > =E2=80=A2 =E2=80=A6 =E2=86=92 =E2=86=A6 =E2=87=92 =E2=88=92 =E2=89=A1 =E2= =8A=A3 =E2=98=85 Not sure why you let me know this (but I'm glad to have it). A priori, I have no problem with any such chars in an Info buffer. Any problems that I would have would I think come from substituting chars that currently have particular meaning to Info (or to Lisp etc. - see above).