How can I associate a codemodel item with its language?

[David Nolden]

Am Montag 31 August 2009 22:07:30 schrieb Milian Wolff:
> David Nolden, 31.08.2009:
> > 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.
>
> Ah, ok:
>         topCtx->parsingEnvironmentFile()->language();
>
> But yeah, I bet that would be 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.
>
> Indeed, with topCtx->parsingEnvironmentFile() that association is there. I
> just looked at parsingEnvironmentFile and that had only a ctor with urls
> which I completely misinterpreted.
>
> > > 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.
>
> Indeed it is not a 1:1 relationship. But we need some way to have the
> classbrowser know the language for a given declaration it gets from the
> code model. I'm still unsure how this would work, but that it is a problem,
> beside not having a proper grouping by language, is shown with this:
>
> Have a project with a cpp and a php file:
>
>
> test.php:
> <?php
> class test {
> function test(){}
> function findPhpClass() {}
> var $phpmember;
> }
>
> test.cpp:
> class test {
> test(){}
> void findCppClass() {}
> int cppmember;
> };
>
> Result:
> http://imagebin.ca/view/vNZO953M.html
>
> I mean this is totally expected, since it only know the identifier for a
> declaration, not its language. It queries the persistent symbol table when
> the item gets expanded, and both times it uses the first item in the
> persistent symbol table...
>
> So we really need _any_ way to associate the lang with an item in the class
> browser... I just thought we'd need to extend the code model since that's
> what the class browser uses...
>
> Is there another way that would also be efficient enough?
In this case a very simple one:
From multiple declarations in the persistent symbol table, just pick the one 
that has the same url as the file from the code-model. That should fully 
resolve this issue.

Greetings, David