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: project terminology Date: Wed, 12 Aug 2015 02:25:30 -0500 Message-ID: <8637zpx91x.fsf_-_@stephe-leake.org> References: <55BE209F.1000009@siege-engine.com> <55BE509B.2080307@yandex.ru> <55C166EF.9060909@gmail.com> <55CA54A3.1030104@yandex.ru> <55CA9808.4000809@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1439364379 9427 80.91.229.3 (12 Aug 2015 07:26:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Aug 2015 07:26:19 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 12 09:26:08 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 1ZPQQJ-0007vt-QK for ged-emacs-devel@m.gmane.org; Wed, 12 Aug 2015 09:26:07 +0200 Original-Received: from localhost ([::1]:37282 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPQQI-0007zZ-W5 for ged-emacs-devel@m.gmane.org; Wed, 12 Aug 2015 03:26:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37501) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPQQA-0007sa-TP for emacs-devel@gnu.org; Wed, 12 Aug 2015 03:26:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZPQQ7-0005Tq-Eq for emacs-devel@gnu.org; Wed, 12 Aug 2015 03:25:58 -0400 Original-Received: from gproxy7-pub.mail.unifiedlayer.com ([70.40.196.235]:45122) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZPQQ7-0005T0-87 for emacs-devel@gnu.org; Wed, 12 Aug 2015 03:25:55 -0400 Original-Received: (qmail 28456 invoked by uid 0); 12 Aug 2015 07:25:49 -0000 Original-Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 12 Aug 2015 07:25:49 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw3 with id 3pRg1r00H2UdiVW01pRjWu; Wed, 12 Aug 2015 07:25:48 -0600 X-Authority-Analysis: v=2.1 cv=Qc314Krv 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=pGLkceISAAAA:8 a=X-HEWhV-kmaYKS9YsLEA:9 Original-Received: from [76.218.37.33] (port=52457 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZPQPs-0005X8-Uu for emacs-devel@gnu.org; Wed, 12 Aug 2015 01:25:41 -0600 In-Reply-To: <55CA9808.4000809@gmail.com> (Eric Ludlam's message of "Tue, 11 Aug 2015 20:49:12 -0400") 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: 70.40.196.235 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:188746 Archived-At: Eric Ludlam writes: > On 08/11/2015 04:01 PM, Dmitry Gutov wrote: >> >> * I wonder what's the main use of having hierarchical projects vs. >> simply tracking several currently open projects (or project roots). >> And how the consumers of the API would take advantage of that >> distinction. >> > > I doubt consumers of the project API would care. Nested projects is > simply something the detection system should enable. I'm puzzled by this terminology; I don't think "nested" means the same thing as "hierarchical"; nested is a subset of hierarchical. For example, here are two possible project layouts on the disk: layout 1: /core # math and IO utils /my_proj # project file includes dependency on /core layout 2: /my_proj # no dependency in project file /core # math and IO utils Other than the layout change, the code is the same (the build scripts that specify paths etc are slightly different). I would call both of these "hierarchical", but only layout 2 is "nested". Apparently, the term "subproject" is also appropriate for core in layout 2. In any case, it would be good to have the option to treat "my_proj" as a single project, that "includes" "core" in any operations that involve searching for things in "the current project". As for distinguishing hiearchical from a simple set of open projects, that's what the project dependency declarations are for. They don't necessarily need to be visible to project.el; some backends may handle that entirely on their own (the Ada mode backend does, for example). > A system that needs to load lisp > code needs to protect against ill formatted lisp code. Putting this > in a core system will help implementations from all creating the same > latent bug. If project.el isn't going to provide detection services, > then it won't need this feature. There is a difference between detecting the presence of a project, and using that project. An extremely simple way to detect projects is to ask the user to specify a project location. Another way is to look for a special file name. Once the project file is found, then it must be loaded. But the detection step (whether ask user or some other method), does not require loading the elisp file (or parsing the project file in general). In the above, I've assumed "project detection" meant "deciding whether there is a project in a disk directory". In other circustances, "project detection" means "pick which of the available projects is appropriate for the current action". It's not always clear from context which meaning is meant. Perhaps we could use the term "project selection" for the latter. In project.el, project-find is used for project selection, but the current implementations of it do project detection as the selection algorithm. Other choices are possible; the "project-explicit" implementation I proposed separates detection from selection. I think EDE is similar, in that it tends to use project detection as part of the selection algorithm. -- -- Stephe