Re: [patch] use font-lock

["Lennart Borgman (gmail)" <lennart.borgman@gmail.com>]

Daniel Colascione wrote:
> 
> 
> 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.

Do you mean font-lock-fontify-region-function?

>  > 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.)

Mumamo now defines what I call "multi major modes". (Previously there 
was a minor mode called mumamo-mode, but that is obsolete.)

Mumamo defines its own font-lock-fontify-region-function that does the 
job. In this function it narrows the buffer to chunks where each chunk 
has its own major mode.

So the main question is: does the parsing happens in the 
font-lock-fontify-region-function that you have defined in nxml-mode? (I 
guess you have defined such a function?)

One thing I think need to be taken care of is nxml-mode starting state 
in chunks handled by mumamo. Is there a way to do that?


> cc-mode also widens the buffer. What's the difference?

Sorry, I do not understand what you mean here.


> 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?

I do not know. Maybe this discussion should be carried over to Emacs 
devel which I think Eric Ludlam reads?


>  > 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.

That would probably be a performance problem.

> But ignoring that distinction,
> hi-lock dynamically adding font-lock keywords is the right way to go.

Yes, it is very nice.

>  > 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.

Thanks, very nice. That mean you can handle <?pyton ... ?> and for 
example py:content="var".

mumamo can help in two ways here:

1) inside <?pyton ... ?> it can use a genshi-mode major mode if there is 
one.

2) inside {% pyton ... %} it can do the same.


> 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".

Good idea IMO.


> 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.

Maybe. But with mumamo it could be a major mode, written with those 
tools that there already are in Emacs.

This could be combined with the schema extending mechanism you suggest.

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/emacs-nxml-mode/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/emacs-nxml-mode/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:emacs-nxml-mode-digest@yahoogroups.com 
    mailto:emacs-nxml-mode-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    emacs-nxml-mode-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/