From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: progmodes/project.el and search paths Date: Mon, 10 Aug 2015 11:43:00 -0500 Message-ID: <86bnefyu0b.fsf@stephe-leake.org> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1439225039 15387 80.91.229.3 (10 Aug 2015 16:43:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Aug 2015 16:43:59 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 10 18:43:48 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 1ZOqAt-0003sy-3K for ged-emacs-devel@m.gmane.org; Mon, 10 Aug 2015 18:43:47 +0200 Original-Received: from localhost ([::1]:59412 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOqAs-0005xj-F0 for ged-emacs-devel@m.gmane.org; Mon, 10 Aug 2015 12:43:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39107) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOqAa-0005x8-IA for emacs-devel@gnu.org; Mon, 10 Aug 2015 12:43:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZOqAW-0006Vz-G8 for emacs-devel@gnu.org; Mon, 10 Aug 2015 12:43:28 -0400 Original-Received: from gproxy10-pub.mail.unifiedlayer.com ([69.89.20.226]:50421) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZOqAW-0006Tv-9t for emacs-devel@gnu.org; Mon, 10 Aug 2015 12:43:24 -0400 Original-Received: (qmail 18358 invoked by uid 0); 10 Aug 2015 16:43:17 -0000 Original-Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy10.mail.unifiedlayer.com with SMTP; 10 Aug 2015 16:43:17 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw2 with id 34j71r01u2UdiVW014jAGM; Mon, 10 Aug 2015 10:43:15 -0600 X-Authority-Analysis: v=2.1 cv=O9qq4nNW c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=9i_RQKNPAAAA:8 a=y7kgw_RnJtkA:10 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=uRRa74qj2VoA:10 a=upSoDu5hoy0F5wPvPhAA:9 Original-Received: from [76.218.37.33] (port=64494 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZOqAH-00008h-LN for emacs-devel@gnu.org; Mon, 10 Aug 2015 10:43:09 -0600 In-Reply-To: <877fp3z8i7.fsf@isaac.fritz.box> (David Engster's message of "Mon, 10 Aug 2015 13:29:52 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 76.218.37.33 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 69.89.20.226 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:188689 Archived-At: 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? I would think that would be done for you by the declared dependency. So Eclipse implicitly adds all the projects to a single "source search path". 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. > 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? Ie, what functions does the user invoke in each case, and what is the result? 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. 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. -- -- Stephe