multilanguage kdevelop

[Milian Wolff]

On Monday, 2. August 2010 14:23:58 Milian Wolff wrote:
> On Saturday, 31. July 2010 22:06:22 David Nolden wrote:
> > The patch looks good. The appended-list stuff is only required if you
> > have declared such lists.
> > 
> > The DUContext.:Language enumerator is redundant with the type itself.
> > You think it's really required? You can just do
> > "dynamic_cast<LanguageDUContext*>(..)" after all.
> 
> I don't know the internals, but I thought it's faster to check an enum
> before doing the dynamic cast is faster, esp. considering that the
> LanguageDUContexts are pretty rare.
> 
> I'd need to do this kind of lookup quite often, e.g. everytime a
> NavigationWidget is supposed to be shown. There I'd need to find the most
> specific language context, get it's LanguageSupport and make it create the
> widget.
> 
> Essentially:
> 
> ctx = topCtx->findContextAt(cursorPos);
> while(ctx != topCtx && ctx->kind() != LanguageDUContexts) {
>   ctx = ctx->parentCtx();
> }
> lang = dynamic_cast<LanguageDUContext*>()->language();
> LangController::language(lang)->createWidget()
>
> > What do you mean by integrating it into the abstract context builder,
> > is there anything you need to do? I anyway think the abstract builders
> > are much too complicated in design. It would be nicer to have "helper"
> > classes instead that would not be part of the builder inheritance
> > chain.
> 
> Well, I need to create the context somewhere. Currently there is only
> support for DUContext and TopDUContext. The latter is hardcoded since it's
> simple to find whether it's recompiling or created from scratch.
> 
> The LanguageDUContext (as would be built in buildEmbedded) otoh is more
> similar to a DUContext and I'd essentially need all the code currently in
> the openContext + openContextInternal methods.

Take a look on how I hacked it in now, I'm very open for suggestions on how to 
do it better:

http://gitorious.org/kdevelop/devel-
kdevplatform/commit/a9ec5195cdefefc6f18048bc321491fbbac85fb5

Note how this is actually only possible with the distinct 'Language' kind as 
far as I can see, since the type is explicitly checked in openContextInternal 
when looking up a context to update.

What do you think?

For the others: CSS inside HTML is now working quite nice, at least the 
NavigationWidgets are correct. Now I have to fix the tests, code completion and 
support inline style="..." tags. Cool :)
-- 
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: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100802/dcac97c1/attachment.sig>