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: Wed, 12 Aug 2015 12:10:34 +0200 Message-ID: <87k2t0yfz9.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> <877fp3z8i7.fsf@isaac.fritz.box> <86bnefyu0b.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1439374278 1304 80.91.229.3 (12 Aug 2015 10:11:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Aug 2015 10:11:18 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 12 12:11:09 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 1ZPSzz-0005HX-Sj for ged-emacs-devel@m.gmane.org; Wed, 12 Aug 2015 12:11:08 +0200 Original-Received: from localhost ([::1]:37773 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPSzz-0005eO-5G for ged-emacs-devel@m.gmane.org; Wed, 12 Aug 2015 06:11:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38184) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPSzh-0005c8-VB for emacs-devel@gnu.org; Wed, 12 Aug 2015 06:10:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZPSze-0007Sf-1O for emacs-devel@gnu.org; Wed, 12 Aug 2015 06:10:49 -0400 Original-Received: from randomsample.de ([5.45.97.173]:42389) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPSzd-0007Le-Hg for emacs-devel@gnu.org; Wed, 12 Aug 2015 06:10:45 -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=GardyMavw5rhpAugHAZVySHEbrFZyCvVxqUo7Vlc4m0=; b=jdhEs/UcvdTv+80/QyI/IJrDscNRjEh/0LNAncv7DD5pQo89EV8/29D44rceT58rbfVyPuZxOL3xnH7Lv9LJOn/roayEpxBUC7Tf2lRlipohJZuzzM5wtuYBklrRamql; 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 1ZPSzW-0005Ym-A4; Wed, 12 Aug 2015 12:10:38 +0200 In-Reply-To: <86bnefyu0b.fsf@stephe-leake.org> (Stephen Leake's message of "Mon, 10 Aug 2015 11:43:00 -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:188751 Archived-At: Stephen Leake writes: > David Engster writes: > >> Stephen Leake writes: >>> 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. > > Do you have to load glibc manually? Yes. You can either create a separate project for glibc and add this to your workspace, or you add the sources of glibc directly to your project as a special "library source". The latter is what you usually do, unless you are a glibc developer. > I would think that would be done for you by the declared dependency. Since you only need the headers for compilation and the library object for linking, there's no need for Eclipse to force you to add the sources. It also cannot add them automatically, because they are usually not installed in the first place. My current Emacs binary depends on 73 libraries, and AFAIK I have sources for exactly none of them installed. > So Eclipse implicitly adds all the projects to a single "source search > path". Not implicitly; you have to configure that. > That is what I'm asking for in Emacs project-related searches. > > load-path does that for elisp. compilation-search-path does that for > most language modes. > > In Ada mode lingo, that group of projects is one hierarchical project; > the project definition files define the project hierarchy. Ada mode > supports having several distict hierarchical projects loaded, but only > one active. > > So that is the source of my confusion. I see. >> 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. > > Depends on the use case; the user might want to see: > > - "all (overloaded) definitions of "foo", in all projects " > > Perhaps to check whether current occurance could be using a > different definition. Or to see if the different definitions could > be combined, or further refactored. > > This is more useful in languages that explicitly support overloaded > symbols (Ada has many definitions of "Put" in its standard library). > > - "the definition for _this_ use of "foo", in some project " > > To see what it actually does. > > - "all methods for this generic function" > > Similar to the first use case, but limited to one generic function. > > So the question now is: what does EDE do for these use cases? AFAIK, you can only search in the current project. However, your use cases involve more than just a project system. If you want to search for overloads or methods, you need a parser as well. This also applies to the most important feature (at least for me): show all definitions of 'foo' that are currently in scope. EDE has no notions of symbols, scope, overloading, methods, etc. It gets much more complicated when you're not only interested in definitions, but any occurance of a symbol. For instance, you want all places where 'foo' gets called, but not any 'foo', but the method 'foo' from class 'bar' and not from any other class. > The definition of xref-find-definitions is agnostic with respect to > these use cases; the "identifier" returned by xref--read-identifier can > be: > > - a simple string for the first use case > > - a more complex structure (in text properties) that identifies this > occurance for the second and third use case > > In addition, the backend can use the extra info or ignore it. > > But the xref-find-definitions UI doesn't allow the user to express a > desire for one these uses. I can't really say much about xref since I haven't really worked with it yet. The semantic-symref feature is also pretty limited in this regard. So in the end, I often ended up calling grep or global directly. All this stuff is highly dependent on the language you're using. > In any case, the "source search path" used by xref-find-definitions > should include all of the relevant projects, as defined by the project > dependencies. I agree. -David