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#16439: [feature request] Highlighting of strings within Info buffers Date: Mon, 20 Jan 2014 10:06:13 -0800 (PST) Message-ID: References: <86lhyic1ik.fsf@somewhere.org> <1394187.cuqsIWxxGs@descartes> <27136a64-176c-4312-a2aa-c86e81091a76@default> <874n4z3tb7.fsf@mail.jurta.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1390241234 4265 80.91.229.3 (20 Jan 2014 18:07:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jan 2014 18:07:14 +0000 (UTC) Cc: ruediger@c-plusplus.de, 16439@debbugs.gnu.org, sva-news@mygooglest.com To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 20 19:07: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 1W5JFo-0008Nj-LR for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Jan 2014 19:07:20 +0100 Original-Received: from localhost ([::1]:53981 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5JFo-0004sn-6W for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Jan 2014 13:07:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5JFe-0004sg-14 for bug-gnu-emacs@gnu.org; Mon, 20 Jan 2014 13:07:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5JFW-0003Mn-Qq for bug-gnu-emacs@gnu.org; Mon, 20 Jan 2014 13:07:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44612) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5JFW-0003Mj-N9 for bug-gnu-emacs@gnu.org; Mon, 20 Jan 2014 13:07:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W5JFW-0002T7-FH for bug-gnu-emacs@gnu.org; Mon, 20 Jan 2014 13:07:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Jan 2014 18:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16439 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16439-submit@debbugs.gnu.org id=B16439.13902411849369 (code B ref 16439); Mon, 20 Jan 2014 18:07:02 +0000 Original-Received: (at 16439) by debbugs.gnu.org; 20 Jan 2014 18:06:24 +0000 Original-Received: from localhost ([127.0.0.1]:58620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W5JEu-0002R3-1a for submit@debbugs.gnu.org; Mon, 20 Jan 2014 13:06:24 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:29387) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W5JEs-0002Qo-Bs for 16439@debbugs.gnu.org; Mon, 20 Jan 2014 13:06:23 -0500 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s0KI6GJE029485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Jan 2014 18:06:17 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s0KI6D8p012249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jan 2014 18:06:14 GMT Original-Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s0KI6D6T020147; Mon, 20 Jan 2014 18:06:13 GMT In-Reply-To: <874n4z3tb7.fsf@mail.jurta.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.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:83801 Archived-At: > The problem is how to highlight strings only in code samples > because in other places highlighting "..." makes no sense. > Look for example in the node (info "(emacs) Package Keywords"): >=20 > Most optional features in Emacs are grouped into "packages". >=20 > Should "packages" be highlighted as a string. Of course not. > There is no additional emphasis on quotations in books. 1. That is not "the problem", IMO. When I proposed this feature, long ago, the complaints (against even providing it optionally, via a user option) were that the highlighting is not foolproof, in that there are some cases where ` or " is not matched (e.g., ?"). For that, I tested each node of the Emacs and Elisp manuals (at the time), and I showed that that problem is very rare. And making the highlighting optional and togglable, deals quite well with that rarity - just hit a key in any of the very few nodes where the highlighting is problematic, to get rid of it. Or turn the option off in your init file if you really prefer what Emacs does now (no such highlighting). 2. Wrt the "problem" you bring up now - Sorry, I don't agree. I've used this feature for decades now, and I can assure you that it is very helpful to have all "..." highlighted. Just my opinion, obviously. It is also possible to separate the control over highlighting of `...' and "...", e.g., by either having different user options or giving the option more possible values. I have not done that in `info+.el', as I have not see the need for it. (However, I do have separate options for `...' and "...", on the one hand, and <...>, on the other.) 3. More importantly, I'm hoping that Emacs will at some point (soon) move to supporting different quoting methods for semantically different constructs, as was discussed in this bug thread: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D16292. I did not bring this up in that thread, because it had already been decided what to do in the immediate, but there are some very different uses of "..." in the Elisp and Emacs manuals. And here I am with you to some extent: "..." to represent a string is different in meaning from "..." to represent, say, the introduction of a glossary term (in-place term definition), which is yet again different from actual quotation (citation), such as the FSF's Back-Cover Text. Strings should be represented using straight " quotes, as is done currently. Actual quotations (citations) should be represented using curly double-quotes. And glossary terms should be represented using either curly double-quotes or another typographical convention (bold or italic is often used for this, but it could also be a different color or other convention). If we do ever represent these different things in different ways, instead of the single "..." notation, then your problem will disappear. 4. During the one or two days that curly single-quotes were actually used in Emacs, during the discussion of bug #16292, I adjusted `info+.el' to DTRT for that, and it worked very well. Unfortunately, the builds for that did not also affect double-quotes, so there was no test for that. But taking care of that in `info+.el' would be trivial also. I'm not knowledgable about TexInfo etc., but I would guess that the changes to support different appearances for what are now handled as "..." would also be straightforward. That is, I would expect that "..." as strings or as term definitions might already be handled differently at the TexInfo level, and are just being mapped to the same Info representation, "...". Just a guess. I see no obstacle to providing helpful highlighting to Emacs such as is provided by `info+.el', except the will of Emacs Dev. FWIW, `info+.el' also highlights <...> (controlled by a separate user option). Thus keys represented using this syntax are highlighted the same as other keys. 5. Note, BTW, that there is no real difference between "..." and `...' wrt "the problem" you cite. Look at the `Top' node of the Emacs manual, for example, and you will see this: This is the `GNU Emacs Manual', updated for That use of `...' is semantically different from its use in `forward-char' or `C-x 4 f' or `.emacs'.