[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Excluding included files / directories from the ind exer 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
