[
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
|
This is one of those "conflicting requirements" situations. Right now
I've gone with the path of putting too much in content assist, just to
make sure we satisfy the user who in the past has gotten too little. As
content assist evolves, we can see about putting filters on what appears
there.
The help thing is a neat idea, but you can't generally rely on it enough
to build a general solution around. Speaking of which, right now I am
removing duplicate entries from the various completion providers. Since
we do not have an open source extension of the help provider, I'm sure
I've broken it. This brings up the need to fill out CDT's support for
open source development (generally gnu on cygwin/mingw/linux) so that we
have more complete and testable solutions out of the box.
Doug.
Thomas Fletcher wrote:
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Ploett Norbert
Sent: Thursday, July 21, 2005 7:27 AM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Excluding included files / directories
from the indexer scan
Hello folks,
this may be sounding a bit strange but we have some header
files that we would rather not have scanned by the indexer
because we do not want to see the definitions we made in the
code completion list. Now those headers are general system
headers, the include path is in an environment variable, and
they are made known to the compiler in the project settings
in a format like ${RMOS_HOME}/inc.
In CDT 2.1.1 paths like this were not scanned by the indexer
and we were happy. Now since about CDT 3.0 RC 1 the undesired
entries start appearing in the code completion list.
So I would appreciate any hints about how the code completion
entries can be avoided (without turning the indexer off altogether).
I think that this is the wrong approach to this problem. I think that we
should be looking at ways in which the help/content assist tools can be
extended with "help content". The current mechanims causes us to more
or less provide a peer to the content assist ... this was done because
in previous versions of CDT (0.x,1.x,2.x) we weren't at a point where
the parsing/indexing was sufficient to span to outside locations.
Now, with 3.0, we are clearly in a much better position than we have
ever been before. This means that external databases (I know that QNX
has one, RedHat had one, apparently Norbert has one too) that provide
information should be unioning (as opposed to appending) their information.
Going the route of excluding paths and files seems to be a step in the
wrong direction. The problem lies in the way that the content is managed
from a historical perspective.
Thanks,
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
