[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: progmodes/project.el and search paths

From: Stephen Leake
Subject: Re: progmodes/project.el and search paths
Date: Sun, 09 Aug 2015 10:55:57 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt)

David Engster <address@hidden> 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

> 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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]