From: Daniel Colascione <danc@merrillpress.com>
To: emacs-nxml-mode@yahoogroups.com
Subject: Re: [emacs-nxml-mode] [patch] use font-lock
Date: Fri, 23 May 2008 18:24:18 -0400 [thread overview]
Message-ID: <200805231824.18563.danc__13752.8749918149$1211581717$gmane$org@merrillpress.com> (raw)
In-Reply-To: <48373CB1.5040302@gmail.com>
On Friday 23 May 2008, Lennart Borgman (gmail) wrote:
> You might wonder how that can be the case. To make it work I implemented
> a workaround where I use the parsing capabilities from nxml-mode to
> check that the files follows the DTD specified syntax, but syntax
> highlighting from another mode (xml-mode/html-mode) that supports
> font-lock.
I saw that you used that approach, and decided to just alter nXML-mode
instead.
I don't really understand why nXML was written to not use font-lock in the
first place. cc-mode had used the complex-matcher approach for a long time,
portably and with few problems. But from having read the font-lock
documentation, one wouldn't suppose this kind of power was available. The
trick of making a matcher that does all the fontification itself and just
returns 'nil' is not documented. Perhaps it should be.
> There is one very disturbing thing with my solution: I can't stop
> nxml-mode from parsing the whole buffer. It parses also those parts
> where mumamo has assigned another major mode. (I hoped that someone some
> day might have the time and skill to look into this, but I did not have
> them.)
> Does you solution handle this problem? If it does, then how does it
> handle it? Does font-lock-fontify-region-function handle also the
> parsing of the xml code? That would be great, but it seems difficult.
I haven't looked at mumamo mode in detail. How does mumamo isolate major modes
to particular areas of the buffer? If you're just narrowing the buffer, I
think going through nXML and removing all the calls to WIDEN should be
sufficient. (Or replacing them with some kind of mumamo-widen.)
cc-mode also widens the buffer. What's the difference?
> Another thing that would be great would be integration with CEDET. As
> you have probably seen nxml-mode is a part of CVS Emacs and CEDET will
> hopefully soon be. Eric Ludlam has done very much work on CEDET recently.
That's good news. I've followed the "IDE features" thread on emacs-devel with
excitement.
> If the completion offered by nxml-mode could be used together with CEDET
> that would be very good. (nXhtml currently offer this in a visible way
> separately, but I believe the long term solution is to go with CEDET -
> at least as an option.)
I don't use CEDET, but if it's getting into Emacs, I might as well give it
another whirl. IIRC, CEDET requires a buffer parser to just generate a set of
tags. What else is required?
> BTW, there is a problem with hi-lock. It uses text properties which may
> be hidden by overlays. IMO it should use overlays with high priorities.
> (That seems to be the easiest solution.)
IMHO, font-lock itself should use overlays. But ignoring that distinction,
hi-lock dynamically adding font-lock keywords is the right way to go.
HIGHLIGHT elements already support a kind of priority through the OVERRIDE
flag, which can be t, prepend, or append, and through ordering on
font-lock-keywords.
> Genshi was new to me. I will add it to mumamo.el.
>
> How did you do the integration with xhtml?
I extended the XHTML schema to support Genshi and XInclude elements and
attributes; I include the original XHTML schema and augment it.
It'd be nice if nXML extended Relax NG to support some kind of schema plugin
mechanism, basically automating what's in qtmstr-xhtml.rnc: e.g. some way of
saying "elements ns:a, ns:b, and ns:c from mylanguage.rnc are at block level
and can contain block-level elements, and ns:d is inline, but can't contain
any children. Oh, and attributes ns:foo and ns:bar can attach to all
elements".
As it is, the best approach for Genshi, IMHO, would be some kind of minor
mode. This mode would add the appropriate font-lock keywords and generate a
temporary schema like the one in qtmstr-xhtml.rnc, only pointing to the
correct xhtml.rnc.
next prev parent reply other threads:[~2008-05-23 22:24 UTC|newest]
Thread overview: 6+ 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 ` Daniel Colascione [this message]
[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)
2008-05-24 2:39 ` [emacs-nxml-mode] " Stefan Monnier
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='200805231824.18563.danc__13752.8749918149$1211581717$gmane$org@merrillpress.com' \
--to=danc@merrillpress.com \
--cc=emacs-nxml-mode@yahoogroups.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).