From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
To: emacs-nxml-mode@yahoogroups.com
Cc: Daniel Colascione <dan.colascione@gmail.com>,
"Eric M. Ludlam" <eric@siege-engine.com>,
Emacs Devel <emacs-devel@gnu.org>,
Steve Yegge <steve.yegge@gmail.com>
Subject: Re: [patch] use font-lock
Date: Sat, 24 May 2008 18:57:55 +0200 [thread overview]
Message-ID: <48384913.3020601@gmail.com> (raw)
In-Reply-To: <200805241103.56336.danc@merrillpress.com>
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.)
------------------------------------
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/
next prev parent reply other threads:[~2008-05-24 16:57 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200805231711.30830.danc@merrillpress.com>
2008-05-23 21:52 ` [patch] use font-lock Lennart Borgman (gmail)
2008-05-23 22:24 ` [emacs-nxml-mode] " Daniel Colascione
[not found] ` <200805231824.18563.danc@merrillpress.com>
2008-05-23 22:50 ` Lennart Borgman (gmail)
2008-05-24 15:03 ` Daniel Colascione
2008-05-24 16:57 ` Lennart Borgman (gmail) [this message]
2008-05-24 2:39 ` [emacs-nxml-mode] " Stefan Monnier
2008-05-23 22:26 Daniel Colascione
2008-05-24 20:38 ` Stefan Monnier
2008-05-25 20:36 ` Daniel Colascione
2008-05-26 14:52 ` Stefan Monnier
2008-05-27 15:13 ` Daniel Colascione
2008-05-27 15:37 ` Stefan Monnier
2008-05-27 15:45 ` Daniel Colascione
2008-05-27 18:37 ` Stefan Monnier
[not found] ` <jwv8wxj8pf9.fsf-monnier+emacs@gnu.org>
2008-06-05 23:07 ` Daniel Colascione
2008-06-05 23:30 ` Lennart Borgman (gmail)
2008-06-06 7:01 ` Stefan Monnier
2008-06-06 7:24 ` Lennart Borgman (gmail)
2008-06-06 7:59 ` Stefan Monnier
2008-06-06 8:09 ` Lennart Borgman (gmail)
2008-06-06 10:09 ` Jason Rumney
2008-06-06 14:23 ` Chong Yidong
2008-06-06 19:04 ` Richard M Stallman
2008-06-06 16:25 ` Michael Olson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48384913.3020601@gmail.com \
--to=lennart.borgman@gmail.com \
--cc=dan.colascione@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=emacs-nxml-mode@yahoogroups.com \
--cc=eric@siege-engine.com \
--cc=steve.yegge@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).