From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: [emacs-nxml-mode] [patch] use font-lock Date: Fri, 23 May 2008 18:24:18 -0400 Organization: Merrill Press Message-ID: <200805231824.18563.danc__13752.8749918149$1211581717$gmane$org@merrillpress.com> References: <200805231711.30830.danc@merrillpress.com> <48373CB1.5040302@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1211581671 4598 80.91.229.12 (23 May 2008 22:27:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 May 2008 22:27:51 +0000 (UTC) To: emacs-nxml-mode@yahoogroups.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 24 00:28:27 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JzfkP-00034M-11 for ged-emacs-devel@m.gmane.org; Sat, 24 May 2008 00:28:27 +0200 Original-Received: from localhost ([127.0.0.1]:55147 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jzfjc-00069z-Pu for ged-emacs-devel@m.gmane.org; Fri, 23 May 2008 18:27:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JzfjA-0005lr-UW for emacs-devel@gnu.org; Fri, 23 May 2008 18:27:09 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jzfj9-0005kO-5o for emacs-devel@gnu.org; Fri, 23 May 2008 18:27:08 -0400 Original-Received: from [199.232.76.173] (port=54246 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jzfj8-0005kB-Va for emacs-devel@gnu.org; Fri, 23 May 2008 18:27:07 -0400 Original-Received: from vpn.merrillpress.com ([64.61.107.78]:58895) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Jzfj7-0005Ao-U2 for emacs-devel@gnu.org; Fri, 23 May 2008 18:27:06 -0400 Original-Received: from pluto.merrillpress.net ([10.136.5.5]) by mars.merrillpress.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Jzfj5-0004rl-EX for emacs-devel@gnu.org; Fri, 23 May 2008 18:27:03 -0400 Resent-From: Daniel Colascione Resent-To: emacs-devel@gnu.org Resent-Date: Fri, 23 May 2008 18:27:03 -0400 Resent-Message-ID: <200805231827.03107.danc@merrillpress.com> User-Agent: KMail/1.9.9 In-Reply-To: <48373CB1.5040302@gmail.com> Content-Disposition: inline X-Length: 4659 X-UID: 391 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Resent-Date: Fri, 23 May 2008 18:27:08 -0400 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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:97624 Archived-At: On Friday 23 May 2008, Lennart Borgman (gmail) wrote: > You might wonder how that can be the case. To make it work I implemented > a workaround where I use the parsing capabilities from nxml-mode to > check that the files follows the DTD specified syntax, but syntax > highlighting from another mode (xml-mode/html-mode) that supports > font-lock. I saw that you used that approach, and decided to just alter nXML-mode instead. I don't really understand why nXML was written to not use font-lock in the first place. cc-mode had used the complex-matcher approach for a long time, portably and with few problems. But from having read the font-lock documentation, one wouldn't suppose this kind of power was available. The trick of making a matcher that does all the fontification itself and just returns 'nil' is not documented. Perhaps it should be. > There is one very disturbing thing with my solution: I can't stop > nxml-mode from parsing the whole buffer. It parses also those parts > where mumamo has assigned another major mode. (I hoped that someone some > day might have the time and skill to look into this, but I did not have > them.) > Does you solution handle this problem? If it does, then how does it > handle it? Does font-lock-fontify-region-function handle also the > parsing of the xml code? That would be great, but it seems difficult. I haven't looked at mumamo mode in detail. How does mumamo isolate major modes to particular areas of the buffer? If you're just narrowing the buffer, I think going through nXML and removing all the calls to WIDEN should be sufficient. (Or replacing them with some kind of mumamo-widen.) cc-mode also widens the buffer. What's the difference? > Another thing that would be great would be integration with CEDET. As > you have probably seen nxml-mode is a part of CVS Emacs and CEDET will > hopefully soon be. Eric Ludlam has done very much work on CEDET recently. That's good news. I've followed the "IDE features" thread on emacs-devel with excitement. > If the completion offered by nxml-mode could be used together with CEDET > that would be very good. (nXhtml currently offer this in a visible way > separately, but I believe the long term solution is to go with CEDET - > at least as an option.) I don't use CEDET, but if it's getting into Emacs, I might as well give it another whirl. IIRC, CEDET requires a buffer parser to just generate a set of tags. What else is required? > BTW, there is a problem with hi-lock. It uses text properties which may > be hidden by overlays. IMO it should use overlays with high priorities. > (That seems to be the easiest solution.) IMHO, font-lock itself should use overlays. But ignoring that distinction, hi-lock dynamically adding font-lock keywords is the right way to go. HIGHLIGHT elements already support a kind of priority through the OVERRIDE flag, which can be t, prepend, or append, and through ordering on font-lock-keywords. > Genshi was new to me. I will add it to mumamo.el. > > How did you do the integration with xhtml? I extended the XHTML schema to support Genshi and XInclude elements and attributes; I include the original XHTML schema and augment it. It'd be nice if nXML extended Relax NG to support some kind of schema plugin mechanism, basically automating what's in qtmstr-xhtml.rnc: e.g. some way of saying "elements ns:a, ns:b, and ns:c from mylanguage.rnc are at block level and can contain block-level elements, and ns:d is inline, but can't contain any children. Oh, and attributes ns:foo and ns:bar can attach to all elements". As it is, the best approach for Genshi, IMHO, would be some kind of minor mode. This mode would add the appropriate font-lock keywords and generate a temporary schema like the one in qtmstr-xhtml.rnc, only pointing to the correct xhtml.rnc.