RE: [cdt-dev] Excluding included files / directories from the ind exer s

[Thomas Fletcher <ThomasF@xxxxxxx>]

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Ploett Norbert
> Sent: July 22, 2005 2:27 AM
> To: CDT General developers list.
> Subject: AW: [cdt-dev] Excluding included files / directories 
> from the indexer scan
> 
[ Overview snipped ]

> This would solve "problem a". Is it already addressed by an 
> enhancemant request?

I don't think so.  This has only recently become an issue now that
the CDT 3.0 parser/indexing/completion story has matured
to a point where non included headers are now providing 
completion proposals (which is not a bad thing at all).  
 
> Now here is the story of my "problem b":
> 

[ Sad story of discontinued compilers and re-arranged arguments ]

Wow ... as someone working for an OS vendor, I have to say that that
would really not be a happy day if I had to put that together.  I guess
that you don't run into any problems with "recursion" of the define
expansion.

> Back to eclipse: When I to "content assist" for func I get to 
> see three
> entries:
> 
> - One from my help provider (which I like)
> - One for the #define (which I don't like)
> - One for the function definition (which is misleading 
> because it shows parameters in reversed order from the 
> standpoint of the application programmer).
> 
> Hence my idea to simply find a mechanism to exclude the 
> header file from content assist. I wonder whether your idea 
> 
> > information should be unioning (as opposed to appending) their
> information.
> 
> would solve even this scenario. It would work only in a "C" 
> environment when a function supplied from an ICHelpProvider 
> would take precedence over suggestions from the indexer.
> In "C++" it would have to be assumed that the same function 
> name with two different parameter lists would be two variants 
> of an overloaded function. Hmmmm...

I don't think so, because I wouldn't expect that functions/methods
with different argument lists would be joined together.  

In your case you would not only want to be able to override the
description for the function, but also potentially its argument
bubble expansion. The JDT suffers this same problem and tries to 
dis-ambiguate based on the context of the call and what you are 
putting into the function.

The other alternative is for us to be able to tack an attribute
on as meta data to the completion information and allow the user
to selectively filter that out.  You see this in the JDT where 
there is a preference to not include methods which have @deprecated 
Javadoc comments.  In the future we would like to do something
similar (ie Doxygen and dynamic hover/help content), which means 
that this whould also be exposed to content providers providing
their help/completion information as plugins.

In this case it wouldn't be so much a deprecated as an "internal"
type of classification.  The way I would see this as working (all
hand waving at the moment):
- You would mark your kernel calls (which are fully prototyped and 
picked up by the parser) as internal/non-visible as part of your 
plugin context information contribution.  In some distant future this could 
potentially even be done in the source code (ala Javadoc).
- The #defines are only partially specified (macro arguments are
non-typed) so your plugin would "enhance/extend" the definition with 
additional argument information and the hover help information.

I think that that approach would allow you to then only have one
entry, likely still marked as a #define, that would contain the
parameters and help from your own database.

Thoughts?
 Thomas