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 20:36:25 -0500 Message-ID: <86si87923q.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> <86si88a6ex.fsf@stephe-leake.org> <55B792D3.8070000@yandex.ru> <86d1zc9tgt.fsf@stephe-leake.org> <55B7AD0D.6070403@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1438133839 11745 80.91.229.3 (29 Jul 2015 01:37:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Jul 2015 01:37:19 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 29 03:37: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 1ZKGIs-0001Hk-Pb for ged-emacs-devel@m.gmane.org; Wed, 29 Jul 2015 03:37:07 +0200 Original-Received: from localhost ([::1]:32990 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKGIr-00032K-RO for ged-emacs-devel@m.gmane.org; Tue, 28 Jul 2015 21:37:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53901) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKGIg-000305-6G for emacs-devel@gnu.org; Tue, 28 Jul 2015 21:36:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKGIa-0000pO-Bc for emacs-devel@gnu.org; Tue, 28 Jul 2015 21:36:54 -0400 Original-Received: from gproxy5-pub.mail.unifiedlayer.com ([67.222.38.55]:44617) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZKGIa-0000hh-4Z for emacs-devel@gnu.org; Tue, 28 Jul 2015 21:36:48 -0400 Original-Received: (qmail 16385 invoked by uid 0); 29 Jul 2015 01:36:38 -0000 Original-Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy5.mail.unifiedlayer.com with SMTP; 29 Jul 2015 01:36:38 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by CMOut01 with id y1cV1q01S2UdiVW011cY6t; Tue, 28 Jul 2015 19:36:37 -0600 X-Authority-Analysis: v=2.1 cv=NJxGpSKg 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=xdMvGWJKhH7MGiE3xS8A:9 Original-Received: from [76.218.37.33] (port=63163 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZKGII-00037t-AQ for emacs-devel@gnu.org; Tue, 28 Jul 2015 19:36:30 -0600 In-Reply-To: <55B7AD0D.6070403@yandex.ru> (Dmitry Gutov's message of "Tue, 28 Jul 2015 19:25: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: 67.222.38.55 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:188152 Archived-At: Dmitry Gutov writes: > On 07/28/2015 06:45 PM, Stephen Leake wrote: > > I think it'll be better to incorporate all related projects into the > notion of the current project, return all project roots on equal > rights, That is certainly what Ada mode does, and gradle. > give project-ignores an argument (one of the roots), and > introduce project-relativize which, like described previously, will > return (ROOT . RELATIVE-PATH). > > In this scheme, project-root is not needed, because we want to treat > all roots somewhat equally, and also because project-root shouldn't > use default-directory, or buffer-file-name. So you would keep project-roots, but not project-root. I can live with that (Ada mode needs neither :). > Not matter if emacs-lisp-mode > sets project-search-path-function, or provides a specialized > implementation of project-search-path, it doesn't know the current > project roots, so it can't exclude them. How will the elisp backend define project-roots? Since it doesn't know anything about project-roots, it should either throw an error, or return nil. On the other hand, (project-search-path (current-project)) in a .el buffer on my machine returns: ("c:/Projects/emacs/master-build-mingw64/lisp/" "c:/Projects/emacs/master/" "c:/Projects/emacs_stephe.main/emacs_stephe/" "c:/Projects/emacs_stephe.main/emacs_stephe_site_lisp/" "c:/Projects/org.emacs.ada-mode/" "c:/Projects/org.emacs.dvc/lisp/" "c:/home/stephe/.emacs.d/elpa/") Those are all 'project-roots' as far as I can tell; they each represent a logically and physically separate collection of elisp source files (except that master-build-mingw64/lisp/ actually has no elisp source files). So for elisp, it seems we are definining project-search-path to be project-roots. Which goes a long way to explaining why this has been so confusing. On the other hand, "(project-directories (project-current))" returns the single root that contains the current .el file; the same as "(project-root (project-current))". Why does project-directories not return a list? Currently, the only code that uses project-directories is xref-find-regexp, and it concats it with project-search-path, so it confuses the two. Ada mode has no need of project-roots. It seems elisp also has no need of project-roots. JDE (Java Development Environment) has no need of project-roots. >> It would be less confusing if the default definition of >> project-search-path did _not_ call project--prune-directories, but >> elisp-search-path _did_. > > Some caller up the stack will have to call project--prune-directories > anyway, because we don't want to guarantee that search-path and > project-roots don't mix (see above). The top-level generic API should be agnostic about that; only the backend knows precisely what project-search-path and project-roots are. In elisp and Ada, project-roots is simply undefined. Ada mode wants search-path to be flat, _not_ containing roots. So it does _not_ what something to call project--prune-directories. > However, we could provide a > public function in project.el that will combine both. Why? I still have not seen an actual use case for project-roots; it seems the simplest thing is to simply drop it. >> The doc string for project-search-path says "source directories", not >> "source root directories". That needs to be fixed. > > All right. To me, the two sound equivalent, and I meant it like that. The difference is whether recursion into subdirectories is required (in this case, allowed); that is always worth documenting; it is normally an option in search functions (think grep vs grep-find; semantic-symref-find-references-by-name has a :scope argument). -- -- Stephe