Submode support in nXML
- First, I don't know a lot of nXML internals, so I can say wrong
things. Please be carefull while reading this, and correct the errors
And two definitions. "Submode": embedded major mode. "Submode
region": region whose content is to be edited with a submode.
I think a common base to all mecanisms could be a modification of
nXML to identify submode regions. While MMM Mode (and nxml-script
too, I think) uses regexps to identify these submode regions, nXML can
do it more robustly, because it effectly parse the XML document. When
nXML identify a submode region, it delegates its processing to a kind
of hook, or a function contained in a variable.
This has the advantage of modify only a few things in nXML itself.
So we can deal with multiple implementations, compare tradeoffs, etc.
And maybe effectively provide multiple implementations within the user
may choose which he want use.
These changes to nXML can be made with something more generic in
mind. Something like "parse events" : "Hey, the parser, because you
are using the XHTML schema, I'm intrested in the event 'encountering a
script element'. So I'm setting a specific variable to a function to
be called when you see this event. Don't forget me." But as I said,
I don't know so much to nXML internals, so maybe I say stupidities.
We have to provide the ability to identify submode regions by
element names, attribute names and PI names, IMHO. By element names
is usefull for elements like XHTML's "script" or "style". By
attribute names is usefull for script or style embedded in attributes,
like the XHTML's "style" or "onclick" attributes. I don't have
concrete example about PI, but I think this is usefull, too.
When this in place, we can consider the two ways discussed in the
past days. I think this is quite trivial to plug MMM Mode in this
interface. It provides a function to MMM-ify a region, which would be
enough. The other way, that is switching explicitely to the submode,
can be implemented, for example, by creating an overlay over the
submode region, telling which submode to use. The switching command
inspects the overlay, get the submode region limits, the submode, and
do what it have to do. Other techniques can be usefull, too.
Some points we have to consider are the deletion of the submode
region (for example deletion of the enclosing element), and modifying
the enclosing element's name (for example from script to anything
else). And other points I don't think about for the moment. For the
deletion of the submode region, I think it is automaticaly managed by
MMM Mode, when the region become zero-length. And I think overlays
have the same functionality. For renaming elements, the parser have
to report the event, to let the implementation to do the right things.
Coming back to the identification of the submode regions by nXML. I
guess this can be placed somewhere in the validation code.
`rng-process-attributes()', `rng-process-start-tag()' and
`rng-process-end-tag()' may be of interest (please tell us if you
think other points are better). I don't found anything like these
related to PIs. These functions can run a specific hook or check an
alist (names -> functions). Both solutions provide the ability to
which is only one test, so it would not slow down the validity code, I
If the user want to use one or other submode managing code, this
code can register a hook in `rng-schema-change-hook'. This hook is
responsible to push the right things in `rng-process-<something>-hook'
or `rng-process-<something>-alist'. For example, if the schema is
the XHTML one, it push functions to deal with "script" and "style"
elements, and "style" attribute, at least.
(BTW, why are `rng-schema-change-hook' and `rng-current-schema'
declared in <FILE:rng-pttrn.el>, instead of <FILE:rng-loc.el>, for
So, I resume :
1/ a few changes to nXML (validity?) code to call functions under
2/ sets of rules, one by supported schema, to register the good
functions to be called in 1/; these rules are processed in
3/ submode managing implementations, telling to 2/ which functions
to register, and defining all they need.
I think all this has the advantage to be modularized enough. nXML
itself doesn't depend on any specific submodes. Anybody can add its
own submode managing implementation. And submode implementations
themself can be enough generic to provide the ability to easy adding
support to some specific submode.
But maybe I didn't consider something that make all this less
simple. Any comment? What do you think about this?
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html