From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.devel Subject: Re: progmodes/project.el and search paths Date: Mon, 10 Aug 2015 13:29:52 +0200 Message-ID: <877fp3z8i7.fsf@isaac.fritz.box> References: <55BE209F.1000009@siege-engine.com> <55BE509B.2080307@yandex.ru> <55BEC1B5.6060204@gmail.com> <86twsgfiuc.fsf@stephe-leake.org> <87mvy2kjxa.fsf@esperi.org.uk> <86si7t11li.fsf@stephe-leake.org> <87lhdkzmdv.fsf@isaac.fritz.box> <86pp2wzcaa.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1439206215 29484 80.91.229.3 (10 Aug 2015 11:30:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Aug 2015 11:30:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 10 13:30:07 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZOlHK-0001C5-Me for ged-emacs-devel@m.gmane.org; Mon, 10 Aug 2015 13:30:06 +0200 Original-Received: from localhost ([::1]:57684 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOlHK-0005ek-1e for ged-emacs-devel@m.gmane.org; Mon, 10 Aug 2015 07:30:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52464) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOlHF-0005cz-En for emacs-devel@gnu.org; Mon, 10 Aug 2015 07:30:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZOlHC-0007Uc-6D for emacs-devel@gnu.org; Mon, 10 Aug 2015 07:30:01 -0400 Original-Received: from randomsample.de ([5.45.97.173]:39800) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOlHB-0007UT-QG for emacs-devel@gnu.org; Mon, 10 Aug 2015 07:29:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=GXZoaxIWliKc97bSxY91BLdXDH/7Km8/UUHOZ71V4Us=; b=Z/pE+bXz8skOv0R2qinv31mN/qqs5+I9gbvA1L3nUavXdeKcpqg7lVaemgQIRNpTklpBsfPF2VNP8ZpxMPLig0GYWVgO6JN71z2GQ6d+MaHKJQkDNFcR10/NtOkdFjjL; Original-Received: from ip4d145d5e.dynamic.kabel-deutschland.de ([77.20.93.94] helo=isaac.fritz.box) by randomsample.de with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZOlHA-0005cq-Bc; Mon, 10 Aug 2015 13:29:56 +0200 In-Reply-To: <86pp2wzcaa.fsf@stephe-leake.org> (Stephen Leake's message of "Sun, 09 Aug 2015 10:55:57 -0500") User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.4 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 5.45.97.173 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:188666 Archived-At: Stephen Leake writes: > David Engster 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. Actually, EDE has support for subprojects. For instance, EDE itself is a subproject of CEDET, just like Semantic, SRecode, and Cogre. Together, they form CEDET. While this is nice in theory, this generates more problems than it is worth. For instance, EDE will generate a recursive Makefile for this, which I'm really not very fond of... >> 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. We are in violent agreement here. Of course you should *have* the source. But I would not put it into a subproject. I want a flat project hierarchy. >>> 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. Sorry, but CEDET is not a library. You might think that the lisp/cedet directory is CEDET, but that's not true (unfortunately, as it makes merging pretty tedious). The files are scattered all over the Emacs sources, which is also why it doesn't make sense to treat lisp/cedet as a "subproject". The grammars are in admin/grammars, SRecode files are in etc/srecode, documentation is in doc/misc, EIEIO is in lisp/emacs-lisp. They are all part of CEDET (though EIEIO is now maintained in Emacs). Originally there was even more (speedbar, for instance). > The fact that it is in Emacs core is just a packaging issue; it doesn't > change the logical structure. First and foremost, we simply have files with the same name scattered across the Emacs source tree. dired.el, custom.el, speedbar.el, shell.el, and many more. This is a very common thing in larger projects, and a project system must be able to handle this. Technically, since lisp/cedet/ede is not in load-path, those two are different files (dired.el and ede/dired.el). Also, all the symbols defined in those files live in different namespaces (dired- and ede-, resp.). So really, the only issue here is when you say "give me the file dired.el from the Emacs project", in which case the project system should tell you that it exists twice and asks you which one to load. But it doesn't matter when you search for symbols. > 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. 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. -David