Supporting multiple languages in a single document

[Milian Wolff]

David Nolden, 17.06.2010:
> Yes, that code looks good, it could work like that. Although maybe it
> would be more "logical" to add the API to ParseJob, and do something
> like:
> backgroundParser->createParseJob(file,
> language)->buildEmbeddedContext(parentContext, range).
> 
> We shouldn't add an additional member to DUContext for this, because a
> DUContext is created for every single function-declaration, and we
> cannot blow up the duchain like that.
> 
> However you can consider either subclass DUContext by a new
> "LanguageDUContext" (which TopDUContext could be based on),

Meaning one would need to dynamic_cast every context while searching, to see 
if it's a language context? Maybe a new ContextType::NestedLanguage kind that 
could be checked beforehand. Yes I think that could work.

> or you
> could add "Language Declarations" into the context to make clear the
> language. Such language declarations could then also be searched
> through findDeclarations directly, which might help with your
> searching problem.

Sorry, but this I don't understand again :( Can you explain a bit more? Do you 
mean something like

LanguageDeclaration->qualifiedIdentifier() == "CSS";
LanguageDeclaratoin->logicalInternalContext() == range between <style> and 
</style>?

Hm yeah that way one could search for the LanguageDeclaration(s) of "CSS" and 
find the declaration in there... But would still need lots of special casing 
in the find methods to prevent finding declarations of other languages. I 
think the former with the context is nicer... Hm tough!

Thanks for your input


-- 
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/1f670ed8/attachment.sig>