From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: info faces for strings and quotations Date: Tue, 5 Oct 2004 21:19:56 -0700 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <200410060225.i962P8s19416@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1097036486 17272 80.91.229.6 (6 Oct 2004 04:21:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 6 Oct 2004 04:21:26 +0000 (UTC) Cc: lennart.borgman.073@student.lu.se, monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 06 06:21:08 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CF3IZ-0000Kl-00 for ; Wed, 06 Oct 2004 06:21:07 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CF3PF-00020u-G0 for ged-emacs-devel@m.gmane.org; Wed, 06 Oct 2004 00:28:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CF3P2-0001xq-3J for emacs-devel@gnu.org; Wed, 06 Oct 2004 00:27:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CF3P0-0001wz-KE for emacs-devel@gnu.org; Wed, 06 Oct 2004 00:27:47 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CF3P0-0001ww-Gw for emacs-devel@gnu.org; Wed, 06 Oct 2004 00:27:46 -0400 Original-Received: from [141.146.126.231] (helo=agminet04.oracle.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CF3Hl-0004zt-Ia for emacs-devel@gnu.org; Wed, 06 Oct 2004 00:20:17 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i964K9iH010096; Tue, 5 Oct 2004 21:20:09 -0700 Original-Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1]) by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i964K9q0031891; Tue, 5 Oct 2004 22:20:09 -0600 Original-Received: from dradamslap (dhcp-amer-csvpn-gw2-141-144-80-130.vpn.oracle.com [141.144.80.130]) by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id i964K4JP031764; Tue, 5 Oct 2004 22:20:04 -0600 Original-To: "Luc Teirlinck" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <200410060225.i962P8s19416@raven.dms.auburn.edu> Importance: Normal X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:27971 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27971 Info highlighting off by default. I can live with that. What do others think? BTW, have you -- have others -- _tried_ the code? Your argument sounds, well, hypothetical. In _practice_, there are only *4* nodes of the Elisp Manual that exhibit any highlighting problem at all, and those pbs are minor. This is a big manual. Yes, it's obvious that there will always be some examples of code in the Info doc (on different programming languages, for instance) that use expressions (e.g. regexp expressions or byte-code examples) that won't highlight 100% correctly. Info highlighting works perfectly 99% of the time, however, including lots of crazy regexp expressions in the Elisp manual (yes, it's surprising). And, the same rare problems can be seen with font-lock highlighting of Emacs Lisp code -- which is presumably one reason we turn off font-lock by default. (Do the doc strings of font-lock functions mention that they "occasionally can lead to anomalous highlighting"? Are we worried about being sued, here, or what?) Some of the rare Info highlighting problems point out things that should really be changed in the Info files themselves, such as ``region'' instead of "region" at node (emacs)Top (highlighted from first ` to first '), or this unnecessary single-quoting of a Lisp sexp at node (elisp)Auto Major Mode: `("\\.gz\\'" FUNCTION t)'. You say that Info markup is "intended for navigation, not highlighting". The `...' convention is explicitly intended to _highlight_ (demarcate, delimit, bring out, set off, draw attention to) commands, key sequences, and perhaps file names. It has absolutely nothing to do with navigating. That's the markup convention I want to exploit here -- that and "..." for strings. This proposal has nothing to do with other, hidden info-file markup; it is all about user-visible "highlighting". Perhaps what you meant was that `...' was not _originally designed_ with an eye to being highlighted. Agreed. But it lends itself to highlighting remarkably well, with no changes needed. Again, I invite you to try it, to see what it does in _practice_. Here is the code, with the latest regexp, which allows escaped chars and newlines inside `...' and "...". (Some Info nodes, like (emacs)Visiting, split a key sequence or command name over two lines.) (defun info-fontify-quotations () "Fontify double-quote strings (\"...\") and text between single-quotes (`...') For single-quotes, use face `info-quoted-name'. For double-quotes, use face `info-string'." (while (re-search-forward "\"\\(?:[^\\\"]\\|\\\\\\(?:.\\|[\n]\\)\\)*\"\\|`\\(?:[^'\\]\\|\\\\\\(?:.\\|[ \n]\\)\\)+'" nil t) (if (eq ?` (aref (match-string 0) 0)) (put-text-property (1+ (match-beginning 0)) (1- (match-end 0)) 'face 'info-quoted-name) (put-text-property (match-beginning 0) (match-end 0) 'face 'info-string)))) Again, to use this, just call `info-fontify-quotations' at the end of `Info-fontify-node' -- add this just before the last line, which is (set-buffer-modified-p nil): (goto-char (point-min)) (when Info-fontify-quotations-p (info-fontify-quotations)) Hoping to hear from more people who have tried the code, regardless of which way your opinion leans. - Drew P.S. FYI, the 4 Elisp-manual nodes that do _not_ highlight 100% correctly are these: - Example Major Modes -- an isolated " (?\") - Index -- an isolated " (" entry in the index) - Auto Major Modes -- the single-quoted Lisp sexp mentioned above - Standard Error -- ' inside "..." inside `...' (`"Symbol's chain of function indirections contains a loop"') -- this too should probably be corrected in the doc itself If the latter two were corrected in the Info files, there would be only *2* nodes of the entire Elisp manual that were not 100% perfect. I don't think we'll be sued. -----Original Message----- From: Luc Teirlinck [mailto:teirllm@dms.auburn.edu] So, what do you and others think of the _desirability_ of (optionally) highlighting quoted expressions in Info? Info files are essentially plain text with some minimal markup that is intended for navigation, not highlighting. So I believe that there is no way that one can do what you are trying to do completely reliably any more than that it is possible to implement Info-hide-note-references completely reliably. To do that, one would need to base the Emacs Info reader on the XML output format instead of on the Info output format. (Maybe somebody might actually do that some day.) So I would suggest that if any feature like this is added to the Emacs Info reader, that it should be done as a user option, that is off by default. Also, the docstring should explicitly mention that it occasionally can lead to anomalous highlighting.