emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Lennart Borgman (gmail)
Subject: Re: [emacs-nxml-mode] [patch] use font-lock
Date: Sat, 24 May 2008 00:50:19 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]