[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: [cdt-dev] Excluding included files / directories from the indexer scan
|
OK, I'll make a new entry and inform you when it is done.
Norbert
-----Ursprüngliche Nachricht-----
Von: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] Im Auftrag von Doug Schaefer
Gesendet: Freitag, 22. Juli 2005 15:27
An: CDT General developers list.
Betreff: Re: [cdt-dev] Excluding included files / directories from the indexer scan
Guys, this discussion should be captured in a bugzilla entry so we don't
lose it.
Doug
Thomas Fletcher wrote:
>
>
>
>
>>-----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
>_______________________________________________
>cdt-dev mailing list
>cdt-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
>
--
Doug Schaefer, Senior Software Developer
IBM Rational Software, Ottawa Lab
Kanata, Ontario, Canada
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
