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