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: Unified project interface Date: Tue, 28 Jul 2015 11:15:53 -0500 Message-ID: <868ua09s1y.fsf@stephe-leake.org> References: <557039DB.4060607@yandex.ru> <85d21bbkqf.fsf@stephe-leake.org> <5570E86B.8070200@yandex.ru> <85iob2a2mm.fsf@stephe-leake.org> <55B2CDA4.8020207@yandex.ru> <868ua5caz6.fsf@stephe-leake.org> <55B441DD.9060806@yandex.ru> <86zj2jb1tx.fsf@stephe-leake.org> <55B517AC.5020401@yandex.ru> <86oaiybvbf.fsf@stephe-leake.org> <55B62B53.5060003@yandex.ru> <861tftaxgx.fsf@stephe-leake.org> <55B78F49.6010101@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1438100208 19807 80.91.229.3 (28 Jul 2015 16:16:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Jul 2015 16:16:48 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 28 18:16:32 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 1ZK7YM-0004ME-6C for ged-emacs-devel@m.gmane.org; Tue, 28 Jul 2015 18:16:30 +0200 Original-Received: from localhost ([::1]:59856 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZK7YL-0007eU-LI for ged-emacs-devel@m.gmane.org; Tue, 28 Jul 2015 12:16:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55275) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZK7Y6-0007cj-NP for emacs-devel@gnu.org; Tue, 28 Jul 2015 12:16:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZK7Xz-00030F-9n for emacs-devel@gnu.org; Tue, 28 Jul 2015 12:16:14 -0400 Original-Received: from gproxy2-pub.mail.unifiedlayer.com ([69.89.18.3]:34101) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZK7Xz-0002yo-3j for emacs-devel@gnu.org; Tue, 28 Jul 2015 12:16:07 -0400 Original-Received: (qmail 16359 invoked by uid 0); 28 Jul 2015 16:16:01 -0000 Original-Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 28 Jul 2015 16:16:01 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw2 with id xsFv1q01H2UdiVW01sFyzP; Tue, 28 Jul 2015 10:15:58 -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=zOBTXjUuO1YA:10 a=vaJtXVxTAAAA:8 a=9B_F4Kt_5H_ePdg6Y_sA:9 Original-Received: from [76.218.37.33] (port=59072 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZK7Xp-0004Xl-K2 for emacs-devel@gnu.org; Tue, 28 Jul 2015 10:15:57 -0600 In-Reply-To: <55B78F49.6010101@yandex.ru> (Dmitry Gutov's message of "Tue, 28 Jul 2015 17:18:49 +0300") 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.18.3 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:188137 Archived-At: Dmitry Gutov writes: > On 07/28/2015 04:21 AM, Stephen Leake wrote: > >>> Could you give an example? >> >> Ada, gradle. > I meant an example (or several) of those declarations from an actual > project file. >From an Ada project file: aggregate project Books_Agg is for Project_Path use ("../../../org.stephe_leake.sal/build/release", "../../../org.stephe_leake.gtk/build/release", "../../../org.stephe_leake.makerules"); for Project_Files use ("books.gpr"); end Books_Agg; with "gtkada"; with "gnatcoll_sqlite"; with "sal"; with "sal_gtk"; with "standard_common"; project Books is for Source_Dirs use ("../../source", "../../test"); ... end Books; Project_Path says where to find projects (there is also an implicit system location); 'with "...";' says what projects to include. In this case, "gtkada" and "gnatcoll_sqlite" are in the system location, and are read only; sal, sal_gtk and standard_common read/write. But the Ada project tool (as provided by the compiler vendor) makes no distinction between "system" and "user" libraries; more precisely, it relies on the file system read/write permissions to do that. >From an Android gradle file: dependencies { compile project(':licensesdialoglibrary') compile project(':quickScroll') compile project(':velocityviewpagerlibrary') compile project(':dragsortlistviewlibrary') compile project(':viewpagerindicatorlibrary') compile project(':circularImageView') compile project(':picasso') compile files('libs/android-async-http-1.4.2-66-g4b6eb97.jar') compile files('libs/commons-io-2.4.jar') compile files('libs/commons-lang3-3.1.jar') compile files('libs/commons-logging.jar') compile files('libs/dashclock-api-r2.0.jar') compile files('libs/google-http-client-1.16.0-rc.jar') compile files('libs/google-http-client-android-1.16.0-rc.jar') compile files('libs/jaudiotagger-2.0.4-20111207.115108-15.jar') compile files('libs/libGoogleAnalyticsServices.jar') compile files('libs/universal-image-loader-1.9.3-with-sources.jar') compile files('libs/com.haarman.listviewanimations-2.6.0.jar') compile files('libs/nineoldandroids-2.4.0.jar') compile files('libs/renderscript-v8.jar') compile 'com.android.support:support-v4:+' compile 'com.google.android.gms:play-services:+' } Some of these are read/write, some are read-only; gradle does not have a mechanism to indicate that. > Here an excerpt from an imaginary Gemfile: > > gem 'foo', '~> 1.2.3' > gem 'bar', path: '../bar' > > Having the latter kind of declaration might not be considered the best > idea, but it's often nice to be able to do that. Anyway, I'm sure > there are corresponding configurations in other ecosystems that are > more idiomatic. The point is that the abstract project API must handle all of these. In the case of Ada, there is a command-line tool that parses the project file and provides the info that Emacs needs. >> I don't know who this "we" is, but I usually structure a large project >> as a main with several lower level libraries, all of which I maintain, >> and I edit them all together to implement new functionality in main. So >> that has to be a choice. > > IME, aside from a few libraries one (person/team/company) maintains > themselves, there's also a long list of external dependencies. Yes, we are agreeing; some dependencies are read/write, some are read-only. How many of each, and whether they are "system" or not, are minor issues. > In the example above, 'bar' will be one of project-directory-roots, > and 'foo' will only be in project-search-path. Why? What effect does that have on what you can do with 'foo' vs 'bar'? How can you tell that just from the gem file? I'm guessing you are saying "foo is maintained by the same team as the main project (ie read/write), bar is maintained elsewhere (ie read-only)". So then files in project-directories are read-only, files in project-search-path are read/write. But the current default implementation of project-search-path _inludes_ project-directories, so this is inconsistent. And we've said that project-directories includes the main project root, so that's also inconsistent. So I don't understand what you are doing here. >> Actually, 'xref-find-regexp' should be named 'project-find-regexp' (or >> prj-find-regexp). Keep 'xref' for strictly cross-reference stuff; > > Sounds good to me. I'll make that change as soon as xref has a > suitable public interface for that. I don't understand; this requires deleting things from xref, not adding to it. The current implementation of xref-find-regexp uses project-current, xref-collect-matches, and xref--show-xrefs. If you make the implementation of project-find-regexp use xref facilities, then I understand your comment. I was hoping for more separation. I suggest renaming 'xref--show-xrefs' to 'project-show-locations', and have it take a list of locations, not implicitly call xref-find-function. Also move all of the location stuff to project; it's more general than xref. xref-collect-matches uses grep; it can simply be moved to project-collect-matches, along with the xref-*grep functions it uses. The doc string needs to mention subdirs. -- -- Stephe