Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] Re: [cdt-patch] Hyperlink Navigation for 2.0

Alain Magloire wrote:

--=_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.
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):

I think we need to clarify here that the project dependencies think Alain is talking about is real the project referenced by a CPathEntry (once we have a working C Path Management System...) where we would resolve referenced projects and their exported include paths and symbols and provided them though the IScannerInfo of the referencing project. (aka binary projects in JDT with the classpaths) I think anything outside of this would result in a misrepresentation of the project wrt building/parsing.

#include <stdio.h>

#include "stdio.h"

Suggestion:

- Search include paths(including dependent projects)
- Fall back to search recursively the project.

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

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



Back to the top