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 04:27:16 -0600 Message-ID: <86r3jw4yrf.fsf@stephe-leake.org> References: <86pp1j4ejm.fsf@stephe-leake.org> <55F899EA.7050700@yandex.ru> <86lhc73wog.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447237775 16207 80.91.229.3 (11 Nov 2015 10:29:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Nov 2015 10:29:35 +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 11:29:24 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 1ZwSeZ-0003aH-43 for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 11:29:23 +0100 Original-Received: from localhost ([::1]:39076 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwSeY-0001y8-98 for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 05:29:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44677) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwSdi-0001u6-EG for emacs-devel@gnu.org; Wed, 11 Nov 2015 05:29:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwScq-0001Cx-1r for emacs-devel@gnu.org; Wed, 11 Nov 2015 05:28:30 -0500 Original-Received: from gproxy10-pub.mail.unifiedlayer.com ([69.89.20.226]:38330) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZwScp-0001Cl-Ne for emacs-devel@gnu.org; Wed, 11 Nov 2015 05:27:35 -0500 Original-Received: (qmail 27569 invoked by uid 0); 11 Nov 2015 10:27:30 -0000 Original-Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy10.mail.unifiedlayer.com with SMTP; 11 Nov 2015 10:27:30 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw2 with id gATL1r00Q2UdiVW01ATPwV; Wed, 11 Nov 2015 03:27:28 -0700 X-Authority-Analysis: v=2.1 cv=Jv9i8qIC 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=upuy2WTQSD7T-eaZwd8A:9 Original-Received: from [76.218.37.33] (port=57616 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZwScc-0004Tv-0z; Wed, 11 Nov 2015 03:27:22 -0700 In-Reply-To: <56429025.3070008@yandex.ru> (Dmitry Gutov's message of "Wed, 11 Nov 2015 02:47:33 +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:194047 Archived-At: Dmitry Gutov writes: > On 11/10/2015 07:36 PM, Stephen Leake wrote: > >>> Although again, what will the project dependencies be used for, is >>> still an open question for me. >> >> The general rule is: if we don't have a good use case, don't add code. > > So I'm not adding it. Just keeping that possibility in mind, and hence > keeping the word "dependency" free. My point is you don't have a good use case for "library", either. At least, the use case for "search only on libraries" is no more important than other similar "search only on ..." use cases. >> Instead, there should just be one path, that includes all files that the >> user might want to do anything with. Then, when the user actually >> invokes a function to do something, they can provide a predicate if they >> want a subset of that. > > How would they provide the predicate when calling the command > interactively? Especially a predicate that would distinguish between > project roots and library roots. In a lot of cases, they will simply search the entire directory list, and filter the results manually as they go thru them. But they can take the time to write a predicate function, and invoke the command via M-; to supply it as an argument in the call. Or they could write a wrapper that provides a list of common predicates. In general, project.el is not about the final user interface, it is about providing core functionality. >>> Since we're discussing project-library-roots here, I'm not sure which >>> improvement you mean. How about simply replacing "the list of >>> directories outside of the project" with "the list of directories >>> outside of the project roots"? >> >> I suggest "not included in" rather than "outside". > > That implies the (not (member ...)) semantics, rather than (not > (file-in-directory-p ...)), which is what > `project-subtract-directories' actually does. Since project-roots is treated recursively, "not included in" means (not (file-in-directory-p ...)) to me. > And "not member" semantics seems pointless to me here; we might as > well allow project-library-roots to include project-roots element, if > the consumer will have to call `project-combine-directories' on them > together. I'm confused. With the current definitions, project-roots and project-library-roots are disjoint, so the user does have to call project-combine-directories if they want to search on both. You now seem to be agreeing with me; it would be better to have only one project-roots function. > Having "library roots" entirely outside the project roots, however, > makes a lot of sense to me intuitively: if they're inside, they are a > part of the project anyway. What kind of use would we have for such > elements? I'm not sure what you are asking here. You seem to be asking "why would we want to search on project-library-roots". But obviously you _do_ want the ability to search on that; that's why it's there. So I must be missing something. >>> We can add "So if the project has dependencies which should be edited >>> together with it, they should go here as well." to the third paragraph >>> of the project-roots docstring. >> >> That would be good. > > Would you be able to give an example of a project file that lists > dependencies like that, that "should be edited together" with the > current project? It would fit the manual well. We have not defined an Emacs project file yet. I can easily provide an Ada example, but I don't think you want that actual file in the Emacs manual. 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 "common" are listed as dependencies in the "map" and "dscovr" Ada project files. Nothing in "map" depends on "dscovr", and vice-versa. All of them depend on the Ada runtime library, which is also in the project search path. All of them are maintained by the GDS team. There is one GDS team member primarily responsible for each mission-level project; I was mostly responsible for the common projects. Any GDS team member can edit any file in any project. The only thing that is a "library" is the Ada runtime library, installed with the Ada compiler. So for the dscovr project, what goes in project-roots, and what goes in project-library-roots, and why? 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 could write a new global xref backend, but it's better to reuse >> existing code. > > Does lisp/cedet/cedet-global.el have code that will help us with > implementing "find definitions" using Global? Yes. I've started an implementation that does that: (defun semantic-symref--xref-find-definitions (symbol &optional symref-tool) "Implement `xref-find-function' for 'definitions for the semantic/symref backend. SYMREF-TOOL determines which symref tool to use (default 'detect); see `semantic-symref-tool-alist'." (require 'semantic/symref) (defvar semantic-symref-tool) (let* ((semantic-symref-tool (or symref-tool 'detect)) (res (semantic-symref-find-tags-by-name symbol 'project)) (hits (and res (oref res hit-lines))) xrefs) (dolist (hit hits) (push (xref-file-location :file (cdr hit) :line (car hit) :column 0) ;; FIXME: add :hint (match-string 3)) xrefs)) xrefs)) >>> IMO, it's more important to have the distinction between "project >>> roots" and "project library roots" in "find regexp" than in "find >>> references". >> >> But you don't provide any code that allows the user to take advantage of >> that distinction. So it how important can it be? > > We have both project-find-regexp and project-or-libraries-find-regexp > already, and I find the difference between them useful in practice. Yes, sorry, I temporarily forgot about those; they are new. xref-find-references needs similar treatment to be consistent. But I think that's the wrong approach; adding a more general user-specified predicate function is much better. -- -- Stephe