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

[Daniel Colascione]

On Friday 23 May 2008 06:50:19 pm Lennart Borgman (gmail) wrote:
> Do you mean font-lock-fontify-region-function?

Sort of. I'm talking about using a function as a matcher keyword in 
font-lock-keywords. This function always returns nil, but while searching, 
sets the face property itself between (point) and its one parameter.

The advantage of using the function-matcher approach is that it interacts 
nicely with other users of font-lock-keywords. cc-mode has used it forever, 
and it seems to work well.

AFAICS, this trick is undocumented.

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

Yes, in that the after-change function that updates bookkeeping information is 
called from the font-lock machinery (via 
font-lock-extend-after-change-function). But it doesn't matter here, because 
at least nxml still keeps some buffer-global information, like the end of the 
XML prolog (which is assume to extend from the start of the buffer to 
nxml-prolog-end).

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

I don't see an easy way to do that. The problem is that nxml needs to widen 
the buffer to see whether the prolog has changed, whether it's scanned as far 
as a given change, and so on. And then it assumes the buffer is contiguous. 
But I didn't write it; there may be a way to deal with the problem.

I'm just speculating here, but what if there were some indirect overlay 
property? It would have the behavior of using, as the overlay content, the 
contents of another buffer. Moving the point in the parent would move the 
point in the child. The child buffer would have its own font-lock setup, and 
the resulting highlighting would show up in the parent.

Using a system like that, you could stitch together multiple child buffers to 
form a parent that looked like it had multiple major modes. And each major 
mode of a child buffer wouldn't know or care about the parent.

> > IMHO, font-lock itself should use overlays.
>
> That would probably be a performance problem.

And a compatibility nightmare, you're right. But I think it would have been a 
better conceptual model.