Re: [emacs-nxml-mode] [patch] use font-lock

[Daniel Colascione]

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.