Supporting multiple languages in a single document

Milian Wolff mail at milianw.de
Thu Jun 17 14:55:54 UTC 2010


Milian Wolff, 17.06.2010:
> David Nolden, 17.06.2010:
> > 2010/6/16 Milian Wolff <mail at milianw.de>:
> > >> Would it be possible to have a single TopDUContext and a tree of
> > >> contexts from mixed language contexts? That would be the most correct
> > >> way to represent them i think.
> > 
> > Why not? It's not a question of the architecture, just of how you
> > create the builders. If they call each other to process sub-contexts
> > of different languages, that should work.
> 
> Can you elaborate? Would you mean something like:
> 
> HTML *Builder::visitStyleTag(node) {
>   LanguagePlugin* css = getLangPlugin("text/css");
>   css->buildEmbeddedContext(document(), getRangeForNode(node),
> currentContext());
> }
> 
> That would of course need that new buildEmbeddedContext in the
> ILanguageSupport. But I have to say: That code up there looks quite good :)
> Much better than my last approach with the second parsejob. I'll take a
> shot at getting something like that to work.

<snip>

> The thing is: I expect (and know of no case where it's different) that
> languages in a document are hierarchical - you cannot have something like:
> 
> Lang A { Lang B { Lang A } }

I'm trying it out right now and am hit by a case which I don't know how to fix 
properly:

<html> // start of html context?
<?php
// php context
?>
</html> // end of html context?

While the structure is actually "HTML | PHP | HTML", there is also a 
dependency between the former and the latter HTML context. If I'd just pass 
single chunks of code / single ranges to the HTML language support plugin, it 
would not be able to create a proper context chain for it's HTML/XML tags...

If one would be able to parse all ranges in one go it could work _in this 
case_

Otoh it's _really_ easy to fubar it anyways, like with e.g.:

<html>
<?php echo '</html>'; ?>

This can never be supported properly...

Anyways, I think many/most templates have a proper structure nowadays and 
should be able to be parsed...

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100617/87951c39/attachment.sig>


More information about the KDevelop-devel mailing list