From: Daniel Colascione <danc@merrillpress.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>
Subject: Re: [patch] use font-lock
Date: Sat, 24 May 2008 11:03:54 -0400 [thread overview]
Message-ID: <200805241103.56336.danc@merrillpress.com> (raw)
In-Reply-To: <48374A2B.1030304@gmail.com>
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.
------------------------------------
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 15:03 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 [this message]
2008-05-24 16:57 ` Lennart Borgman (gmail)
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=200805241103.56336.danc@merrillpress.com \
--to=danc@merrillpress.com \
--cc=dan.colascione@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=emacs-nxml-mode@yahoogroups.com \
--cc=eric@siege-engine.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).