Re: progmodes/project.el and search paths

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

David Engster <deng@randomsample.de> writes:

> Stephen Leake writes:
>>
>> But if you are in glibc, looking at an identifier for a function that
>> happens to be defined in the linux kernel, you want to be able to find
>> the corresponding definition; the linux kernel is a subproject of
>> glibc (which is a subproject of higher level projects like Emacs).
>
> I must say I find this to be a very unusual view. Just because a program
> depends on libc, the libc is not a "subproject". 

We are arguing about the definition of the word "subproject".

The Oxford English Dictonary doesn't define it.

Wiktionary says: 

   A project within a larger project.

I agree libc is not "within" Emacs, so apparently I'm using the word
wrong.

> Instead, you have a
> dependency on a library which has a fixed API. 

"dependency" is fine with me. 

"fixed API"; only sometimes. If I have control over both the top level
project and the dependency, it is sometimes advantageous to change the
API to better implement some feature.

> The only thing you need are the declarations of the API and the needed
> type definitions, 

Sometimes. There were _many_ times at NASA when I wished we had paid the
contractor to deliver the full source code, rather than an API and user
guide.

Certainly in Emacs the doc string is often not enough, and I need to
read the body of the function to find out what's actually going on.

I often feel the need to do that in Android, but I haven't developed the
search/cross-reference skills to be able to yet.

> which are given through the system headers, 

Not all libraries are "system", but libraries do provide headers, yes.

Whether and where a library is "installed" is a packaging/distribution
detail; it should not impact this discussion.

> I don't care how printf is implemented; 

There are some libraries you trust (hopefully the ones you are paying
for), and others not so much.

>> So the Emacs project tools should reflect that. For example, file name
>> completion must handle duplicate file names. That's a problem right now
>> in Emacs for elisp files; there are both lisp/cedet/ede/dired.el and
>> lisp/dired.el in Emacs core.
>
> This is a different problem. 

Ok, now we are getting somewhere; this is one example of the kind of
problems I'm trying to address.

> You are within one project here; 

No, 'cedet' is a library as far as I'm concerned; it has an API, I try
to treat it as a black box. 

The fact that it is in Emacs core is just a packaging issue; it doesn't
change the logical structure.

The fact that Emacs locate-library searches within it just indicates
that Emacs got it right from my point of view :).

ELPA packages are also libraries; they are included in load-path when I
need them, and not otherwise.

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.

Same for identifier completion, find parent/child declarations, etc.

-- 
-- Stephe