How can I associate a codemodel item with its language?

[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?
-- 
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/20090831/b62e3e2f/attachment.sig>