KDE/kdevplatform/language/duchain
Andreas Pakulat
apaku at gmx.de
Mon Sep 15 18:23:16 UTC 2008
On 15.09.08 18:47:25, David Nolden wrote:
> Am Montag, 15. September 2008 18:31:31 schrieb Andreas Pakulat:
> > On 15.09.08 15:28:46, David Nolden wrote:
> > > SVN commit 861252 by zwabel:
> > >
> > > Add a comment to the assertion. Now we need to think how to load
> > > language-supports on demand.
> >
> > So you now need language support without even having a file opened from
> > that language? I'd have to check at the API but that shouldn't be too
> > hard.
>
> The problem is, that KDevelop tries to load a DUContext of a type that
> currently doesn't exist within KDevelop, because the language-support that
> contains that type isn't loaded. The class-browser does some processing while
> startup that can trigger this.
>
> I think we need to do this: Store the name of the language-support in each
> top-context, and when attempting to load a top-context, first check whether
> the needed language-support is there, and if it isn't, load it.
Sounds fine to me, I guess its important that its the exact same plugin
that has created the types? Then using the pluginname as plugin-id is
the "safest" you can do right now. I'd prefer using the
X-KDevelop-Language because its independant of the actual name, but at
least in theory someone could write a different plugin using other
types for the same language... Your choice, let me know if you need any
help.
Andreas
--
You will be called upon to help a friend in trouble.
More information about the KDevelop-devel
mailing list