Re: [cdt-patch] Hyperlink Navigation for 2.0

[Bogdan Gheorghe <gheorghe@xxxxxxxxxx>]

cdt-patch-admin@xxxxxxxxxxx wrote on 12/08/2003 11:56:57
AM:

> > 
> > --=_mixed 00794D9285256DF3_=
> > Content-Type: multipart/alternative; boundary="=_alternative
> 00794D9285256DF3_="
> > 
> > 
> > --=_alternative 00794D9285256DF3_=
> > Content-Type: text/plain; charset="US-ASCII"
> > 
> > Here is the first go at Hyperlink navigation for CDT 2.0. The
main points:
> > 
> > * Navigation can be turned on/off from the C Editor preference
page
> > 
> > * To activate hyperlinks, hold the Ctrl key down and move the
mouse over 
> > the element you want to navigate to; clicking the button is equivalent
to 
> > F3/selecting Open Declarations
> > 
> > * Opening includes works as well (as long as the file can be
found - ie. 
> > make sure to set up the paths properly if you are referencing
external 
> > files) - this equivalent to selecting 'Open Include' from the
outline 
> > view. I should also mention that I modified the behaviour of
the 
> > OpenIncludeAction a bit. The workflow used to be: i) Search the
project's 
> > include paths for the file in question, ii) If the file was not
found on 
> > any of the include paths, search the project itself. This has
been changed 
> > to: i) Search include paths, ii) Search project regardless of
what was 
> > found. 
> > 
> 
> We overlook the contribution of other projects.  When we set
dependencies
> on a project we also export there include paths.  For example,
> IProject("application"), IProject("library"),
 "application" depends
> on "library".
> When looking for include paths we should look at the dependent 
> project's scannerProvider include paths.

When you say dependencies, do you mean  project
references? If yes, then I'm not sure if this 
is correct. I always thought that Project A referencing
Project B means that Project B's build output
is a prerequsite for building Project A...and that's
all. Any Project B include file paths that are used 
by Project A still need to be entered in Project A.

> IMHO, there is a flaw in IScannerInfo since it does not allow to 
> make a distinction between
> include paths system/compiler builtins and contribution on the 
> command lines(-I ..) , it makes a difference when doing
> this, (We address this in the ICPathEntry):
> 
> #include <stdio.h>
> 
> #include "stdio.h"
> 
> Suggestion:
> 
> - Search include paths(including dependent projects)
> - Fall back to search recursively the project.

By always searching the include paths first, you could
be finding the wrong file. What if you have #include "foo.h"?
The parser first tries to search for "foo.h"
locally before trying to find it on the include paths. We would currently
look for it
amongst the include paths and quit if we found it
in one of the directories - even if it's not the one that is actually being
used.

I can redo the Action to take into account what type
of include is used - ie. mimic what the parser actually does. If it's #include
"foo.h", I'll look locally and then, if not found, I'll look
on the include paths. If it's #include <foo.h>, I'll look solely
on the include paths. This way, if the user chooses to open the file they'll
get the file actually used by the parser. What do you think?

>
> I do not quite follow, this:
>    ii) Search project regardless of what was 
> Why ? if you already find a match.

I changed it so that if more than one file is found
amongst the include paths/project, the user can say which one he really
wants. I thought that since we're not giving truly accurate results, we
might as well give them all the results.

> _______________________________________________
> cdt-patch mailing list
> cdt-patch@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-patch