Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • Daniel Colascione
    ... 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
    Message 1 of 8 , May 24, 2008
    • 0 Attachment
      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.
    • Lennart Borgman (gmail)
      ... Is not that documented in `font-lock-keywords ? But maybe you mean it could be more explicit? ... I am not sure what you mean here. Mumamo calls
      Message 2 of 8 , May 24, 2008
      • 0 Attachment
        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.)
      Your message has been successfully submitted and would be delivered to recipients shortly.