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: project.el semantics Date: Wed, 11 Nov 2015 16:14:21 -0600 Message-ID: <86wptob2v6.fsf@stephe-leake.org> References: <86pp1j4ejm.fsf@stephe-leake.org> <86mvwn11u1.fsf@stephe-leake.org> <55F8E451.9080902@yandex.ru> <86bnd21q0r.fsf@stephe-leake.org> <55F97EA2.9000408@yandex.ru> <86mvwmz58h.fsf@stephe-leake.org> <55F9A5F8.1030505@yandex.ru> <86pp1ixem2.fsf@stephe-leake.org> <55FAFC36.5010506@yandex.ru> <86twqrww0u.fsf_-_@stephe-leake.org> <563EA9B9.5080404@yandex.ru> <86vb9dufs0.fsf@stephe-leake.org> <563F4915.1080008@yandex.ru> <867flrbksb.fsf@stephe-leake.org> <56409F2D.9060300@yandex.ru> <86mvun9gz7.fsf@stephe-leake.org> <56415902.90103@yandex.ru> <86h9ktah9x.fsf@stephe-leake.org> <56429025.3070008@yandex.ru> <86r3jw4yrf.fsf@stephe-leake.org> <564340DC.5020008@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447280107 23067 80.91.229.3 (11 Nov 2015 22:15:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Nov 2015 22:15:07 +0000 (UTC) Cc: John Wiegley , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 11 23:14:56 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 1ZwdfK-0004F9-P0 for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 23:14:55 +0100 Original-Received: from localhost ([::1]:43290 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwdfK-0000ep-Ca for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 17:14:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54969) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwdf6-0000ej-Uy for emacs-devel@gnu.org; Wed, 11 Nov 2015 17:14:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zwdf3-0002k9-69 for emacs-devel@gnu.org; Wed, 11 Nov 2015 17:14:40 -0500 Original-Received: from gproxy2-pub.mail.unifiedlayer.com ([69.89.18.3]:59575) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Zwdf2-0002jY-VP for emacs-devel@gnu.org; Wed, 11 Nov 2015 17:14:37 -0500 Original-Received: (qmail 23362 invoked by uid 0); 11 Nov 2015 22:14:31 -0000 Original-Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy2.mail.unifiedlayer.com with SMTP; 11 Nov 2015 22:14:31 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by CMOut01 with id gNEN1r00N2UdiVW01NER1x; Wed, 11 Nov 2015 15:14:30 -0700 X-Authority-Analysis: v=2.1 cv=VOBOwb/X 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=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=qtqOOiqGOCEA:10 a=vaJtXVxTAAAA:8 a=-2wVH36haQ9u9hkQbpoA:9 Original-Received: from [76.218.37.33] (port=49701 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1Zwdep-000552-Cr; Wed, 11 Nov 2015 15:14:23 -0700 In-Reply-To: <564340DC.5020008@yandex.ru> (Dmitry Gutov's message of "Wed, 11 Nov 2015 15:21:32 +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.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:194163 Archived-At: Dmitry Gutov writes: >> In general, project.el is not about the final user interface, it is >> about providing core functionality. > > Providing core functionality for third-party code that's not, usually, > written by the user either. So it's exactly the business of project.el > to include the kind of metadata like "these are the directories the > user might be interested in, but the user doesn't own the code > inside". Ok, I can see the need for some sort of metadata. But that suggests: (cl-defgeneric project-metadata (project dir) "Return interesting metadata for DIR in PROJECT." ...) We need more examples of useful metadata before we can begin to design a format for the return result. >> Any case where a large project is divided into subprojects, all of which >> are editable. For example, my NASA GDS projects looked like this: >> >> GDS >> sal >> >> common >> >> map >> >> dscovr >> >> All four of these are projects. "sal" and "common" are lower level; they >> are used by "map" and "dscovr", which are the projects used by the MAP >> and DSCOVR missions respectively (you can Google those ...). "sal" and > > You work on very cool projects, no question about it. :) Used to; I'm retired now. I worked on robots before that; even more fun. >> "common" are listed as dependencies in the "map" and "dscovr" Ada >> project files. Nothing in "map" depends on "dscovr", and vice-versa. > >> So for the dscovr project, what goes in project-roots, and what goes in >> project-library-roots, and why? > > Then project-roots will contain dscovr, sal and common. And > library-roots will have what's left in the search path (Ada runtime > library). You did not answer the most important part of the question: "why?". I'm left with "in order to decide which directories go in project-root vs project-library-root, ask Dmitry". > Personally, I expect that to be useful (e.g. limiting searches to the > projects that you control). But if not, you an also disregard that > distinction. Do you see any downsides to it? Yes; it's not flexible enough. There were times when I wanted to search only in map/, or only in sal/. I just used grep-find. I could only dream about the other use cases I described, but they did come up. For refactoring, I would make a low-level change, that would generate lots of compiler errors (Ada is a big help here). Then I would maintain a manual list of which ones were fixed in a text file. Some more structured system would be nice. >> Note that the Ada project tool provides only one "source search path"; >> it does not distinguish between "libraries" and "non-libraries". For the >> dscovr project, "dscovr", "sal", "common", and the runtime library are >> in the search path. > > I'm hoping that you can still distinguish sal and common from the > standard library somehow, programmatically. Only by knowing the directory layout of the disk; the Ada project doesn't care, so it doesn't know. >> xref-find-references needs similar treatment to be consistent. But I > > Thus far xref-find-references doesn't depend on the presence of > "current project" (some implementations might use, some might not). > > So creating two variations of xref-find-references would be > incongruous, even if maybe useful. Right. On the other hand, a user-defined predicate would be a reasonable feature for xref-find-references. > If you only accept user-specified predicates, you're assuming that the > project backend can't provide any useful information to classify the > directories. The predicate can query the metadata, via project-metadata. > I'm open to the ideas in this direction, but the UI must be better than M-:. We have to agree that the UI is a separate discussion, or we will get nowhere. -- -- Stephe