Supporting multiple languages in a single document
Milian Wolff
mail at milianw.de
Thu Jun 17 09:34:23 UTC 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.
One question I have though: How should we differentiate between declarations
in different languages? I think something like this should do the trick:
IndexedString DUContext::language() const;
DUContext::setLanguage(const IndexedString lang);
Now each of the current findDeclaration-like methods would by default skip
contexts of a different language. If someone wants to have declarations of a
different language, he'd need to explicitly query for those somehow, either by
new set of functions or by passing another parameter to the find* methods.
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 } }
That makes the current findDeclaration* methods easy to adapt. Otoh searching
for declarations in a _different_ language would require to go down the
context tree until we finally find a context of that language, where we could
then again use one of the existing findDeclaration* methods.
Because of this, I'd say introducing a new
QList<Declaration*> findDeclarationInLanguage( QualifiedIdentifier,
IndexedString language );
should do the trick.
What do you say?
--
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/c18f39df/attachment.sig>
More information about the KDevelop-devel
mailing list