From: Stephen Leake <stephen_leake@stephe-leake.org>
To: emacs-devel@gnu.org
Subject: Re: progmodes/project.el and search paths
Date: Sun, 09 Aug 2015 10:55:57 -0500 [thread overview]
Message-ID: <86pp2wzcaa.fsf@stephe-leake.org> (raw)
In-Reply-To: <87lhdkzmdv.fsf@isaac.fritz.box> (David Engster's message of "Sun, 09 Aug 2015 14:17:48 +0200")
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
next prev parent reply other threads:[~2015-08-09 15:55 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-02 13:52 progmodes/project.el and search paths Eric Ludlam
2015-08-02 17:17 ` Dmitry Gutov
2015-08-03 1:19 ` Eric Ludlam
2015-08-03 16:16 ` Stephen Leake
2015-08-03 22:56 ` Dmitry Gutov
2015-08-08 13:07 ` Nix
2015-08-09 5:18 ` Stephen Leake
2015-08-09 12:17 ` David Engster
2015-08-09 15:55 ` Stephen Leake [this message]
2015-08-10 11:29 ` David Engster
2015-08-10 16:43 ` Stephen Leake
2015-08-12 10:10 ` David Engster
2015-08-12 13:49 ` Stephen Leake
2015-08-12 15:36 ` David Engster
2015-08-13 11:53 ` Nix
2015-08-13 12:05 ` Dmitry Gutov
2015-08-14 11:52 ` Eric Ludlam
2015-08-14 22:30 ` Dmitry Gutov
2015-08-15 0:48 ` Eric Ludlam
2015-08-15 7:05 ` Eli Zaretskii
2015-08-10 17:12 ` Nix
2015-08-03 22:47 ` Dmitry Gutov
2015-08-04 11:52 ` Eric Ludlam
2015-08-04 16:09 ` Dmitry Gutov
2015-08-03 13:49 ` David Engster
2015-08-03 14:09 ` Dmitry Gutov
2015-08-03 14:27 ` David Engster
2015-08-03 15:13 ` Dmitry Gutov
2015-08-03 21:35 ` David Engster
2015-08-03 23:21 ` Dmitry Gutov
2015-08-04 8:15 ` David Engster
2015-08-04 13:43 ` Eli Zaretskii
2015-08-04 18:05 ` Dmitry Gutov
2015-08-04 18:16 ` Eli Zaretskii
2015-08-04 18:41 ` Dmitry Gutov
2015-08-04 19:23 ` Eli Zaretskii
2015-08-04 19:40 ` João Távora
2015-08-05 2:52 ` Eli Zaretskii
2015-08-04 20:15 ` Dmitry Gutov
2015-08-05 2:49 ` Eli Zaretskii
2015-08-05 6:18 ` Stephen Leake
2015-08-05 15:08 ` Eli Zaretskii
2015-08-05 15:36 ` Dmitry Gutov
2015-08-05 16:31 ` Eli Zaretskii
2015-08-05 16:45 ` David Engster
2015-08-05 22:17 ` Dmitry Gutov
2015-08-06 7:56 ` Stephen Leake
2015-08-06 7:54 ` Stephen Leake
2015-08-05 9:42 ` Dmitry Gutov
2015-08-05 15:23 ` Eli Zaretskii
2015-08-05 15:31 ` Dmitry Gutov
2015-08-05 16:16 ` Eli Zaretskii
2015-08-06 6:44 ` Dmitry Gutov
2015-08-06 7:43 ` Stephen Leake
2015-08-06 10:25 ` Dmitry Gutov
2015-08-06 14:27 ` Stephen Leake
2015-08-06 23:16 ` Dmitry Gutov
2015-08-07 14:10 ` Stephen Leake
2015-08-07 14:44 ` Dmitry Gutov
2015-08-03 16:35 ` Stephen Leake
2015-08-03 16:45 ` Eli Zaretskii
2015-08-03 21:07 ` Stephen Leake
2015-08-03 21:33 ` David Engster
2015-08-04 2:35 ` Eli Zaretskii
2015-08-03 15:09 ` Eli Zaretskii
2015-08-03 15:16 ` Dmitry Gutov
2015-08-03 15:29 ` Eli Zaretskii
2015-08-03 19:01 ` Dmitry Gutov
2015-08-03 19:19 ` Eli Zaretskii
2015-08-03 21:05 ` Dmitry Gutov
2015-08-04 11:48 ` Eric Ludlam
2015-08-04 16:20 ` Dmitry Gutov
2015-08-03 16:25 ` Stephen Leake
2015-08-03 21:33 ` Stefan Monnier
2015-08-03 22:15 ` David Engster
2015-08-03 22:50 ` Dmitry Gutov
2015-08-04 7:13 ` Stefan Monnier
2015-08-04 8:13 ` David Engster
2015-08-05 13:42 ` Stefan Monnier
2015-08-06 11:27 ` {Spam?} " Eric Ludlam
2015-08-06 23:10 ` Stefan Monnier
2015-08-07 11:18 ` Eric Ludlam
2015-08-07 11:43 ` David Engster
2015-08-07 12:17 ` Dmitry Gutov
2015-08-07 12:40 ` David Engster
2015-08-07 12:54 ` Dmitry Gutov
2015-08-07 12:08 ` Alexis
2015-08-04 9:40 ` Stephen Leake
2015-08-04 17:43 ` Dmitry Gutov
2015-08-04 19:49 ` Stephen Leake
2015-08-04 20:03 ` Dmitry Gutov
2015-08-05 6:02 ` Stephen Leake
2015-08-05 9:59 ` Dmitry Gutov
2015-08-06 7:25 ` Stephen Leake
2015-08-07 14:21 ` Dmitry Gutov
2015-08-05 1:29 ` Eric Ludlam
2015-08-11 20:01 ` Dmitry Gutov
2015-08-12 0:49 ` Eric Ludlam
2015-08-12 7:25 ` project terminology Stephen Leake
2015-08-12 9:28 ` progmodes/project.el and search paths Dmitry Gutov
2015-12-29 2:00 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86pp2wzcaa.fsf@stephe-leake.org \
--to=stephen_leake@stephe-leake.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.