[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
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
- progmodes/project.el and search paths, Eric Ludlam, 2015/08/02
- Re: progmodes/project.el and search paths, Dmitry Gutov, 2015/08/02
- Re: progmodes/project.el and search paths, Eric Ludlam, 2015/08/02
- Re: progmodes/project.el and search paths, Stephen Leake, 2015/08/03
- Re: progmodes/project.el and search paths, Dmitry Gutov, 2015/08/03
- Re: progmodes/project.el and search paths, Nix, 2015/08/08
- Re: progmodes/project.el and search paths, Stephen Leake, 2015/08/09
- Re: progmodes/project.el and search paths, David Engster, 2015/08/09
- Re: progmodes/project.el and search paths,
Stephen Leake <=
- Re: progmodes/project.el and search paths, David Engster, 2015/08/10
- Re: progmodes/project.el and search paths, Stephen Leake, 2015/08/10
- Re: progmodes/project.el and search paths, David Engster, 2015/08/12
- Re: progmodes/project.el and search paths, Stephen Leake, 2015/08/12
- Re: progmodes/project.el and search paths, David Engster, 2015/08/12
- Re: progmodes/project.el and search paths, Nix, 2015/08/13
- Re: progmodes/project.el and search paths, Dmitry Gutov, 2015/08/13
- Re: progmodes/project.el and search paths, Eric Ludlam, 2015/08/14
- Re: progmodes/project.el and search paths, Dmitry Gutov, 2015/08/14
- Re: progmodes/project.el and search paths, Eric Ludlam, 2015/08/14