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

[Lennart Borgman (gmail)]

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

Is not that documented in `font-lock-keywords'? But maybe you mean it 
could be more explicit?


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

I am not sure what you mean here. Mumamo calls font-lock-fontify-region 
(after trying to set the variables needed for the chunks major mode). 
Does that work together with your approach?


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

It is a general problem. Js2 has a similar problem. (I am cc:ing Steve 
Yegge too ;-)


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

I have been thinking about different such possibilities. AFAICS it would 
be much simpler if the parsing modes (like nxml-mode) are aware of what 
should be parsed in the buffers. Other possibilities tends to be very 
complex.

So I would suggest that something like mumamo divides the buffer into 
chunks with different major modes. Then the parsing mode and mumamo (or 
something similar) should communicate to tell what chunks should be 
parsed and what chunks should not be parsed. (The major mode itself is 
not enought to tell if a chunk should be parsed or not. For example a 
<style> ... </style> chunk in xhtml can be parsed by nxml-mode. Ie 
nxml-mode does not care much about the content of it.)

Doing it that way I see two problems:

1) The parser must be able to somehow support a "parse region" 
functionality.

2) Parsing states for the different chunks must be initialized somehow. 
I would suggest carrying over the last state from the previous chunk if 
needed. (Sometimes assuming that the parsing state at the beginning of 
the chunk is the "zero state" is enough, sometimes not.)

As you noticed the parser must somehow start from the beginning of the file.

Font lock could cheat a bit and start in the middle of a file so parsing 
and font-lock style syntax highlighting do not have the same needs. 
Maybe that can be handled by doing the syntax highlighting in two 
passes, the first pass similar to font-lock currents way and the second 
pass doing parsing?

This would allow editing with the benefit of syntax highlighting 
(font-lock style) while the parser works in the background, doing the 
second pass. When the support of the parser is needed (for example for 
completion) the user of course would have to wait for the parser to 
catch up.



How would such a scheme fit js2 and the changed nxml-mode? (I guess 
there is more work to support it in both modes and a framework similar 
to jit-lock would have to be used for the parsing.)