How can I associate a codemodel item with its language?

[David Nolden]

Am Montag 31 August 2009 21:01:00 schrieb Milian Wolff:
> David Nolden, 31.08.2009:
> > Am Mittwoch 26 August 2009 01:30:02 schrieb Milian Wolff:
> > > I want to add per-language grouping to the class browser, but am stuck:
> > >
> > > It uses the CodeModel to get the items, but how do I decide to which
> > > language a given item is associated? Not even declarations / contexts
> > > seem to have any association with a language...
> >
> > Top-contexts have an association to the language.
> >
> > The problem is that you cannot access those from within the code-model
> > right now I think.
> >
> > So the simplest way would be using the file-extensions to do the
> > filtering, as that is basically all that is known at that point.
> >
> > Greetings, David
>
> I don't like this workaround, maybe I should fix the real issue? Or would
> associating the language with a code model result in increased disk-size
> for the repo again or something like that?

The code-model is an extremely simplified view of the code, and it is good 
that way as it allows efficiently accessing only the really most important 
information.

Right now it is just a map from a filename to a set of declaration-names 
within minimum information:
( Filename -> [ [Declaration-name, declaration-kind], .... )

And I don't know where the information about the language should be integrated 
there. The "Declaration-name" entries are not bound to a specific declaration, 
and there could be multiple declarations of the same item, maybe even from an 
arbitrary set of items.

What could be done without paying a high price would be adding a mapping 
(Filename -> language), but that would also not really work in your case as 
there can be multiple languages for one file.

> I mean grouping by file extension could potentially really be error prone,
> lets do it correctly and use the information we have... And I bet accessing
> the topducontext for every class would be too slow, right?
If it would use the same information for assigning languages to filenames that 
is available to the language-controller, it would be exactly equivalent. The 
problem is that the languages are assigned through mimetypes, and that stuff 
is using KUrls, and is very inefficient. 

> Though I have to admit that even in the TopDUContext I wouldn't have the
> slightest clue how to get it's language plugin to query ::name()...
I think each top-context has a language() function, or at least each 
ParsingEnvironmentFile. But I guess using that information for grouping in the 
class-browser is not really an option, as you would first have to load the 
top-context, which is too slow.

> The only thing I know of is the ParsingEnvironmentFilePointer, but that is
> per-url. I bet this would be a problem as soon as we have e.g. JavaScript
> support and files where we have both, JavaScript declarations and PHP
> declarations in the same file (somewhat ugly imo but you never know what
> users do...).
It is not per-url, but per-topducontext. An arbitrary amount of topducontexts 
can be created for each url.

> Can you give me some pointers on how/where to integrate something like
> ParsingEnvironmentFilePointer for CodeModel items?
You mean a direct link between the code-model and ParsingEnvironmentFile? As 
said, this is not a 1:1 relationship: There can be an arbitrary amount of top-
contexts for each url, and an arbitrary amount of declarations for each code-
model item. So such a direct link can not be cleanly created. The code-model 
can only be used to get a very simplified structure of the code, and in order 
to make the step into the real duchain, an indirect query has to be done.

Greetings, David