Re: progmodes/project.el and search paths

[Stephen Leake <stephen_leake@stephe-leake.org>]

David Engster <deng@randomsample.de> writes:

> Stephen Leake writes:
>> The same problem occurs with any language library projects; if I'm
>> working on top_project, and need to read the impelementation for a
>> function that happens to be in library_project_1, they both need to be
>> in the file completion search path.
>
> Say I really want to see the implementation of 'foo' in glibc. I simply
> load the glibc project into my workspace (to use the Eclipse lingo); it
> is not a subproject, but simply another project parallel to all the
> others I have loaded. I can now jump from some Emacs C source file to
> the 'foo' definition.

Do you have to load glibc manually? I would think that would be done for
you by the declared dependency.

So Eclipse implicitly adds all the projects to a single "source search
path".

That is what I'm asking for in Emacs project-related searches.

load-path does that for elisp. compilation-search-path does that for
most language modes.

In Ada mode lingo, that group of projects is one hierarchical project;
the project definition files define the project hierarchy. Ada mode
supports having several distict hierarchical projects loaded, but only
one active.

So that is the source of my confusion.

> My guess your issue is that another library might have defined a symbol
> 'foo' as well, and its project is also loaded in my workspace - then it
> depends on the #include's in your source file. So here, a project system
> must ask something like Semantic for the search path of the current
> file.

Depends on the use case; the user might want to see:

- "all (overloaded) definitions of "foo", in all projects "

    Perhaps to check whether current occurance could be using a
    different definition. Or to see if the different definitions could
    be combined, or further refactored.

    This is more useful in languages that explicitly support overloaded
    symbols (Ada has many definitions of "Put" in its standard library).

- "the definition for _this_ use of "foo", in some project "

    To see what it actually does.

- "all methods for this generic function"

    Similar to the first use case, but limited to one generic function.
    
So the question now is: what does EDE do for these use cases?

Ie, what functions does the user invoke in each case, and what is the
result?


The definition of xref-find-definitions is agnostic with respect to
these use cases; the "identifier" returned by xref--read-identifier can
be:

- a simple string for the first use case

- a more complex structure (in text properties) that identifies this
  occurance for the second and third use case

In addition, the backend can use the extra info or ignore it.

But the xref-find-definitions UI doesn't allow the user to express a
desire for one these uses.

In any case, the "source search path" used by xref-find-definitions
should include all of the relevant projects, as defined by the project
dependencies. 

--
-- Stephe