[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [emacs-nxml-mode] [patch] use font-lock
From: |
Daniel Colascione |
Subject: |
Re: [emacs-nxml-mode] [patch] use font-lock |
Date: |
Fri, 23 May 2008 18:24:18 -0400 |
User-agent: |
KMail/1.9.9 |
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.